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EXECUTIVE  SUMMARY 

Space  Surveillance  Network  (SSN)  Optical  Augmentation  (SOA) 


Surveillance  of  space  is  essential  for  effective  space  control.  Surveillance  of  space 
provides  space  situational  awareness  which  is  the  foundation  of  space  superiority.  The 
SSN  has  deep  space  coverage  and  capacity  limitations  in  deep  space  surveillance. 

Too  many  objects  receive  inadequate  tracking  and  the  problem  will  only  get  worse  as 
the  number  of  objects  on-orbit  increases.  The  purpose  of  this  initiative  was  to 
demonstrate  the  potential  for  remote,  autonomous  collection  and  reporting  of  metric 
data  to  augment  the  optical  deep  space  tracking  capabilities  of  the  SSN.  The 
demonstration  used  low  cost,  commercial  off-the-shelf  technology  to  increase  the 
capacity  and  performance  of  the  SSN  by  off-loading  the  routine  tasking  and  observation 
burden  from  more  capable  telescopes. 

The  Air  Force  Research  Laboratory/DEBI  (AFRL)  submitted  the  SOA  concept  to  the 
Space  Battlelab.  The  Space  Battlelab's  General  Officer  Advisory  Group  (GOAG) 
approved  the  initiative  for  execution  with  $590,000  on  1 1  September  1997. 

The  Space  Battlelab  conducted  the  demonstration  at  the  18th  Space  Surveillance 
Squadron,  Edwards  AFB,  CA  from  28  July  through  14  August  1998.  During  the 
demonstration,  AFRL  was  responsible  for  the  telescope  control  system  and  for 
performing  data  reduction.  The  Massachusetts  Institute  of  Technology  Lincoln 
Laboratory  (MIT/LL)  was  responsible  for  object  scheduling,  a  weather  protection 
system,  and  communications  between  Socorro,  NM  and  Edwards  AFB. 

The  demonstration  met  its  objectives: 

Objective  1 :  SOA  successfully  demonstrated  remote,  autonomous  collection  and 
reporting  of  metric  data  on  deep  space  objects.  During  the  demonstration  period, 
the  system  produced  nearly  6,000  metric  observations  without  any  human 
intervention. 

Objective  2:  SOA  demonstrated  the  value  added  of  geographically  dispersed 
sensors  to  the  SSN.  SOA  collected  data  when  the  Socorro  and  Maui  Ground- 
based  Electro-Optical  Deep  Space  Surveillance  (GEODSS)  sites  were  out  of 
operations  due  to  bad  weather.  However,  the  observations  were  not  reported 
into  the  operational  system  at  Cheyenne  Mountain  Air  Station  (CMAS),  therefore 
the  impact  on  SSN  performance  of  dispersed  sensors  was  not  directly  measured. 

The  throughput  of  the  system,  if  operated  in  a  mode  consistent  with  what  was 
learned  during  this  test,  is  between  40  and  45  satellite  attempts  per  hour.  SOA’s 
acquisition  rate,  throughput,  and  accuracy  are  similar  to  GEODSS.  SOA’s  less  capable 
telescopes  are  still  able  to  see  70%  of  deep  space  objects.  SOA  is  a  low-cost  ($5-7M 
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for  three  sites  based  upon  an  independent  cost  estimate  from  Aerospace  Corporation) 
augmentation  to  the  SSN  with  an  estimated  O&M  cost/object  of  $6  compared  to  $38  for 
baseline  GEODSS  and  $15  dollars  for  refurbished  GEODSS. 

One  of  the  benefits  of  SOA  is  its  use  of  astrometry,  where  the  position  of  the  stars 
determines  the  position  of  the  satellites.  Not  only  is  the  accuracy  of  the  observations 
(up  to  5  times  better  than  GEODSS)  better  than  with  a  system  that  uses  mount 
encoders,  but  if  multiple  satellites  appear  in  the  image,  the  position  of  all  of  the  satellites 
can  be  determined  simultaneously.  The  current  GEODSS  system  does  not  use 
astrometry. 

In  general,  the  system  configuration  used  for  the  SOA  demonstration  was 
successful.  The  availability  and  operational  status  of  the  autonomous  SOA  telescope 
and  data  analysis  system  was  high.  However,  there  are  two  hardware  changes 
identified  during  the  demonstration  that  would  substantially  improve  the  system 
performance:  expand  the  telescope  FOV  and  minimize  the  telescope  mount  limitations. 

The  Space  Battlelab  conducted  SOA  to  demonstrate  an  innovative  low-cost 
approach  to  meet  some  of  Air  Force  Space  Command’s  (AFSPC)  space  surveillance 
requirements.  Based  on  this  successful  demonstration,  the  Space  Battlelab 
recommends  AFSPC  fund  the  acquisition  of  three  upgraded  SOA-like  systems  with  1- 
degree  field-of-view  (FOV)  telescope  and  tracking  mounts  in  FY02.  HQ  AFSPC  should 
deploy  the  three  systems  to  ensure  redundant  coverage  of  deep  space.  In  addition  to 
the  coverage  improvements,  the  SSN  capacity  would  also  improve.  Although  the  total 
capacity  shortfall  would  still  exist,  three-telescope  augmentation  should  allow  the  SSN 
to  meet  the  GEODSS  ORD  requirement  to  track  all  deep  space  objects  once  every 
three  days.  In  addition,  SOA  should  significantly  reduce  the  number  of  objects  on  the 
attention  and  lost  list.  At  the  time  of  this  After  Initiative  Report,  HQ  AFSPC/DRC  is 
building  the  FY02  POM  input  to  acquire  SOA-like  systems. 
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1.  DEMONSTRATION  MISSION  STATEMENT 
A.  Purpose 

The  purpose  of  the  SOA  initiative  was  to  demonstrate  remote,  autonomous 
collection,  and  reporting  of  metric  data  to  augment  the  optical  deep  space  tracking 
capabilities  of  the  Space  Surveillance  Network  (SSN).  The  demonstration  used  low 
cost,  commercial  off-the-shelf  technology  to  increase  the  capacity  and  performance  of 
the  existing  network  of  sensors  by  off-loading  the  routine  tasking  and  observation 
burden  from  more  capable  telescopes.  SOA  gives  flexibility  by  freeing  these  telescopes 
to  do  more  of  the  difficult  missions  of  search  and  space  object  identification  (SOI),  for 
which  they  are  designed,  or  more  metrics  as  the  need  varies. 

1.  Background 

Surveillance  of  space  is  essential  for  effective  space  control.  Surveillance  of 
space  provides  space  situational  awareness  which  is  the  foundation  of  space 
superiority.  The  Ground-based  Electro-Optical  Deep  space  Surveillance  System 
(GEODSS)  Operational  Requirements  Document  dated  20  Nov  96  defined  the  tracking 
requirements: 

As  a  system  (GEODSS),  the  threshold  for  collecting  metric  data  for  space 
catalog  maintenance  of  satellite  orbital  parameters  is  one  track  per  deep-space  object 
every  three  days.  This  frequency  of  tracking  is  an  average  required  to  maintain  element 
sets  on  non-maneuvering  deep  space  objects  to  an  accuracy  permitting  subsequent 
reacquisition.  The  objective  is  one  track  per  deep  space  object  every  day. 

As  a  system  (GEODSS),  the  threshold  for  collecting  metric  data  for  maneuver 
and  conjunction  detection  is  one  track  for  every  maneuverable  object  per  day.  This 
tracking  frequency  ensures  detection  of  a  maneuvering  satellite  before  it  moves  so  far 
from  its  assumed  position  it  becomes  lost.  The  objective  is  two  tracks  for  every 
maneuverable  object  every  day. 

Metric  data  is  position,  velocity  vector  and  time  parameters  used  to  determine 
orbit  ephemeris.  The  optical  network  consists  of  GEODSS  sites  at  Socorro,  NM,  Maui, 
HI  and  Diego  Garcia,  each  with  three  1  meter  telescopes  and  Ebsicon  cameras,  and  the 
Transportable  Optical  System  (TOS)  in  Moron,  Spain  with  a  single  24  inch  telescope 
and  CCD  camera. 

The  optical  network,  while  able  to  perform  its  mission,  is  limited  in  its  capacity 
and  coverage.  Today  the  1st  Command  and  Control  Squadron  (1  CACS)  tasks  the 
network  to  track  over  2,000  objects  in  deep  space.  On  average,  the  optical  network 
tracks  objects  once  every  three  days.  However,  the  SSN  has  not  tracked  approximately 
15  percent  of  cataloged  deep  space  objects  in  5  -  30  days  and  10  percent  in  more  than 
30  days,  which  are  on  the  lost  list.  The  Optical  Network  Mission  Study  (ONMS) 
sponsored  by  AFSPC  and  considered  to  be  the  most  credible  study  to  date  projected 
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that  the  number  of  deep  space  (DS)  objects  will  increase  significantly  by  the  year  2005 
(see  Figure  1).  Scheduled  SSN  sustainment  upgrades  will  not  keep  pace  with  this 
projected  increase.  In  addition,  there  is  little  overlap  in  sensor  coverage  (see  Figure  2) 
in  the  European  and  Asian  regions. 


Sensor  Overlap 

A  Radar  Sites 


I  I  No  Sensor  Overlap 
A.  Optical  Sites 


Figure  2  SSN  Deep  Space  Coverage 
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Cloud  coverage  sometimes  precludes  sensor  operation  and  thus  affects  the 
performance  of  the  network.  Weather  at  Diego  Garcia  precludes  operation  ~50%  of  the 
time.  Weather  at  Moron  Spain  precludes  operation  -20%  of  the  time. 

The  Space  Battlelab  conducted  SOA  to  demonstrate  an  innovative  low-cost 
approach  to  meet  some  of  AFSPC’s  deep  space  surveillance  requirements. 

B.  Length  of  Time 

1.  Submittal  of  Battlelab  Initiative  to  Approval 

Air  Force  Research  Laboratory  (AFRL)  /DEBI  submitted  the  SOA  concept  to 
the  Space  Battlelab  on  9  June  1997.  The  Space  Battlelab  presented  the  concept  to  the 
Battlelab  Planning  Cell  (BPC)  on  31  July  1997.  The  Space  Battlelab  General  Officer 
Advisory  Group  (GOAG)  approved  the  SOA  concept  for  detailed  planning  on  8  August 
1997  and  for  execution  on  1 1  September  1997.  The  GOAG  allocated  SOA  $440K  in 
FY97  and  $150K  in  FY  98  for  the  demonstration.  The  total  time  from  submittal  to 
execution  approval  was  three  months. 

2.  From  Approval  to  Completion 

The  execution  of  SOA  began  on  1 1  September  1997.  The  Space  Battlelab 
completed  the  demonstration  on  14  August  1998. 

C.  Objectives  and  Measures  of  Merit 

Primary  Objective  1  -  Demonstrate  remote,  autonomous  collection  and  reporting 
of  metric  data  on  deep  space  objects  for  use  by  USSPACECOM  in  the  maintenance  of 
the  satellite  catalog.  Measure  of  merit  for  collection  was  the  ability  of  the  system  to 
autonomously  execute  an  observation  schedule,  based  on  a  daily  tasking  message 
originating  from  1st  Command  and  Control  Squadron  (1  CACS),  by  accurately  pointing, 
tracking,  observing  and  correlating  observations  in  a  timely  manner  with  a  high 
throughput.  Measure  of  merit  for  reporting  was  the  ability  to  report  correlated 
observations  to  a  geographically  separated  location. 

Primary  Objective  2  -  Demonstrate  the  value  added  of  geographically  dispersed 
sensors  to  the  SSN.  Measure  of  merit  was  the  ability  to  improve  the  quality  of  the 
USSPACECOM  element  set  database  by  decreasing  the  number  of  objects  on  the  lost 
list  or  increasing  the  accuracy  of  the  database  with  more  frequent  observations  during 
the  demonstration. 
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2.  COURSE  OF  ACTION 
A.  Overview 

The  Space  Battlelab  worked  with  both  AFRL/DEBI  and  the  Massachusetts 
Institute  of  Technology  Lincoln  Laboratory  (MIT/LL)  to  conduct  the  demonstration.  The 
Space  Battlelab  conducted  the  demonstration  at  the  18th  Space  Surveillance  Squadron 
(18  SPSS),  Edwards  AFB  CA.  During  the  demonstration,  AFRL  was  responsible  for  the 
telescope  control  system  and  data  reduction.  MIT/LL  was  responsible  for  object 
scheduling,  a  weather  protection  system,  and  communications  between  Socorro,  NM 
and  Edwards  AFB. 

The  nightly  operations  flow  (Figure  3)  was  as  follows: 


Figure  3  Nightly  Operations  Flow 

1)  1  CACS  indirectly  tasked  the  system  to  collect  metric  observations.  With  no 
direct  connections  to  Cheyenne  Mountain  Air  Station  (CMAS),  the  system  took  the 
tasking  1  CACS  sent  to  both  the  Socorro  and  Maui  GEODSS  site  and  combined  them  to 
create  the  tasking  for  SOA. 

2)  The  MIT/LL  Optical  Dynamic  Scheduler  Prototype  (ODSP),  residing  at  the 
MIT/LL  Eastern  Test  Site  (ETS),  Socorro,  New  Mexico,  took  the  combined  tasking  as 
input  and  developed  a  schedule  for  metric  collections.  The  feedback  loop  shown 
between  the  telescope  and  the  scheduler  allowed  the  scheduler  to  know  if  an  individual 
metric  collection  was  successful.  In  addition,  the  telescope  indicated  if  stars  were 
present  in  the  image  for  a  weather  exclusion  zone  program  included  in  ODSP.  This 
program  allowed  the  scheduler  to  avoid  scheduling  metrics  in  regions  of  the  sky  that 
were  cloud  covered. 

3)  The  telescope  control  system  autonomously  (no  human  in  the  loop)  received 
specific  object  tasking  and  the  most  recent  element  set  from  the  ODSP.  The  telescope 
control  system  determined  the  correct  pointing  angles  for  the  telescope,  pointed  the 
telescope,  and  initiated  the  collection  of  the  observation. 
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4)  The  system  automatically  downloaded  the  resulting  frames  of  data  from  the 
charged-coupled  device  (CCD)  camera.  The  system  processed  the  resulting  frame(s) 
into  standard  reporting  format  (B3)  for  metric  observations  and  sent  the  observations  to 
the  scheduler. 

AFRL  and  MIT/LL  each  logged  and  analyzed  the  results  to  determine  system 
performance. 

B.  Detailed  System  Description 

Figure  4  shows  a  schematic  overview  of  the  system. 


Figure  4  SOA  System  Overview 
1.  Optical  Dynamic  Scheduler  Prototype  (ODSP) 

a.  Background 

HQ  AFSPC  has  planned  for  a  substantial  refurbishment  and  sustainment 
program  for  the  GEODSS  system.  Ultimately,  the  refurbishment  will  include 
replacement  of  the  control  computers  as  well  as  the  aging  Ebsicon  cameras.  The 
refurbished  GEODSS  systems  will  be  the  primary  component  of  an  integrated  optical 
sensor  network  controlled  from  a  central  facility  located  at  Edwards  Air  Force  Base  in 
California.  This  facility,  the  Optical  Command  Control  and  Communication  Facility 
(OC3F)  at  the  18th  Space  Surveillance  Squadron,  will  provide  centralized  dynamic 
scheduling  of  metric,  search,  and  space  object  identification  (SOI)  tasking  to  all  optical 
sensors  in  the  SSN.  Litton/PRC  developed  the  OC3F  software  as  a  major  part  of  the 
GEODSS  Modification  Program  (GMP).  The  OC3F  tasks  the  entire  optical  network  as 
a  single  unit  and  adjusts  tasking  based  on  individual  sensor  capabilities,  coverage, 
operational  status,  weather  and  capacity. 
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In  support  of  the  development  of  the  OC3F  centralized  dynamic  scheduler, 
MIT/LL  developed  the  Optical  Dynamic  Scheduler  Prototype  (ODSP).  The  ODSP  is  a 
natural  extension  of  the  dynamic  scheduler  used  by  the  Transportable  Optical  System 
(TOS)  deployed  in  Moron,  Spain  which  provides  real-time  dynamic  scheduling  for  a 
single  optical  telescope  using  multiple  scheduling  criteria. 

b.  ODSP  Design  Overview 

The  heart  of  the  ODSP  is  the  SKYMAP  propagator  and  memory  region. 
This  memory  region  contains  the  element  sets,  physical  characteristics,  and  the 
geocentric  and  topocentric  positions  of  each  satellite  in  the  deep  space  object  catalog. 

The  SKYMAP 
propagator  maintains  the 
geocentric  and 
topocentric  positions  and 
recomputes  the  position 
of  each  object  several 
times  a  minute. 

For  each 
scheduling  request,  the 
ODSP  calculates  a  figure 
of  merit  for  each  tasked 
satellite.  The  ODSP 
then  commands  the 
sensor  to  observe  the 
object  with  the  highest 
figure  of  merit. 

In  Figure  5, 
we  present  a  simple 
example  of  one  of  the 
scheduling  criteria, 
satellite  elevation.  In  this 
example,  the  scheduler 
attempts  to  favor  scheduling  of  satellites  at  high  elevation,  when  viewing  conditions  are 
optimal.  However,  ODSP  never  schedules  a  satellite  with  an  elevation  of  less  than  5° 
due  to  the  mechanical  limitations  of  the  GEODSS  mount.  For  other  sensors,  different 
elevation  limits  can  be  set.  For  azimuth/elevation  mounts,  an  upper  elevation  limit  is 
generally  required  to  avoid  the  mount  singularity  at  the  zenith.  The  cause  of  the  mount 
singularity  is  the  inability  of  the  mount  to  slew  over  the  top;  instead,  it  must  slew  all  the 
way  around  to  reach  the  other  side.  Note  that  simply  returning  a  weighting  function  of 
zero  would  not  be  sufficient  to  guarantee  that  ODSP  would  not  schedule  the  object.  In 
general,  we  can  graphically  represent  each  of  the  scheduling  criteria,  although  the 
variables  represented  on  the  x-axis  may  vary  from  criteria  to  criteria. 
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Figure  5  Sample  Weighting  and  Screen  Function 
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As  a  second  example,  consider  the  weighting  function  for  mean  anomaly. 
A  common  problem  with  GEODSS  operations  is  that  they  tend  to  cause 
geosynchronous  satellites  to  be  observed  at  approximately  the  same  time  of  the  night. 
In  terms  of  the  orbital  elements,  it 
also  observes  the  object  at 
roughly  the  same  mean  anomaly 
each  night.  Consequently,  the 
GEODSS  system  clusters  the 
observations  it  supplies  to  the 
Space  Control  Center  along  the 
same  limited  portion  of  the 
satellite  orbit.  The  result  is  poor 
sampling  of  the  orbit  and  a  poor 
orbit  determination.  To  mitigate 
this  problem,  the  ODSP  retains 
the  mean  anomalies  of  the  last 
three  tracks  on  each  tasked 
object.  It  defines  a  weighting 
function,  shown  in  Figure  6.  This 
weighting  function  prevents 
scheduling  of  the  object  at  the 

same  mean  anomaly  on  subsequent  tracks  and  increases  sampling  of  the  orbit. 

(1)  Weather  Exclusion  Zone  Program 
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Figure  6  ODSP  Mean  Anomaly  Weight  Function 


The  ODSP  maintains  an 
exclusion  zone  map  for  the  purposes  of 
scheduling  optical  sensors  under  partly 
cloudy  conditions.  This  map  divides  the 
visible  hemisphere  of  sky  into  69  regions 
(see  Figure  7).  Each  of  these  regions  can 
be  marked  as  excluded  by  the  sensor. 
Generally,  the  sensors  use  this  feature  to 
prevent  scheduling  of  satellites  within 
regions  of  the  sky  which  are  unobservable 
due  to  clouds,  nearby  buildings,  or  other 
adverse  conditions.  The  centralized 
scheduler  at  the  OC3F  will  support 
exclusion  zone  maps  for  each  sensor  site 
when  the  current  GEODSS  upgrade 
program  is  complete.  However,  there  are 
currently  no  operational  exclusion  zone 
sensors  (EZS)  at  the  GEODSS  sites. 

During  the  SOA 
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demonstration,  we  used  an  alternative  method  of  maintaining  this  exclusion  zone  map 
using  only  the  SOA  telescope  itself.  With  this  approach,  each  time  the  sensor  reported 
a  weather  miss  on  a  scheduled  metric  track,  the  scheduler  set  the  corresponding  zone 
in  the  exclusion  zone  map  to  cloudy.  This  prevented  the  scheduler  from  giving  the 
sensor  a  second  satellite  in  the  same,  probably  cloudy,  region  of  the  sky  and  forced  it  to 
move  to  new,  potentially  clear  regions.  The  scheduler  automatically  reset  the  region  as 
clear  after  approximately  20  minutes.  Thus,  the  sensor  itself  maintained  the  exclusion 
zone  map.  Potentially,  this  technique  would  allow  sensors  without  an  EZS  systems  to 
populate  the  exclusion  zone  map  at  OC3F  using  the  existing  interface  and  post-upgrade 
OC3F  functionality. 

c.  ODSP  Computer  Hardware 


The  ODSP  and  centralized  metric  observation 
correlator  described  below  executed  on  a  Motorola  MVME-167 
single  board  computer  at  ETS  (see  Figure  8).  The  single  board 
computer  supports  both  System  V  Unix  and  a  real-time 
executive  called  RTUX.  The  68040  microprocessor  is  its  base. 
For  the  ODSP  system,  two  single  board  computers  are  used. 
The  first  serves  as  the  host  Unix  system  and  executes  the 
ODSP  and  correlation  processes.  The  SKYMAP  process 
executed  on  the  second,  running  the  real-time  executive 
RTUX.  Near  the  top  of  the  photograph,  one  can  see  the 
Netblazer  dial-on-demand  router  (left,  beneath  telephone  and 
Lucent  SDD-1910  secure  data  device  (right)). 

2.  Centralized  Metric  Observation  Correlation 
Processing 

One  of  the  basic  functions  of  the  OC3F  is  to  provide 
centralized  correlation  of  metric  observations  for  all  component 
sensors  using  its  authoritative  database.  The  ODSP  software 
used  for  the  SOA  demonstration  also  had  this  functionality, 


Figure  8  ODSP 
Computer  and 
Communication 
Hardware 


although  MIT/LL  modified  the  correlation  algorithms  to 

accommodate  the  4-5  minute  delay  in  data  delivery  of  the  SOA  sensor  used  for  the 
demonstration.  ETS  made  modifications  to  the  algorithm  to  repropagate  (to  propagate 
back)  candidate  satellites'  element  sets  to  the  time  of  the  observation.  The  correlation 
algorithm  used  by  the  ODSP  is  very  similar  to  the  algorithm  employed  in  the  TOS.  This 
algorithm  makes  use  of  both  the  satellite  angular  position  and  velocity,  making  it 
significantly  more  robust  than  the  observation/object  correlation  algorithms  used  in  the 
Space  Control  Center. 


The  real-time  correlator  relies  on  the  same  SKYMAP  memory  region  for  real¬ 
time  dynamic  scheduling.  Upon  receipt  of  metric  data  from  the  sensor,  the  correlator 
calculates  an  average  angular  velocity  for  the  track  using  the  first  and  last  metric 
observation.  Next,  SKYMAP  identifies  all  satellites  in  the  immediate  area  of  the 
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observed  position  at  the  time  of  the  observation.  Finally,  in  order  to  correlate  the 
observation  with  the  correct  satellite,  SKYMAP  computes  a  four  dimensional  coefficient 
for  each  satellite  identified.  It  selects  the  satellite  that  produces  the  largest  value  that 
also  passes  several  criteria  called  screens. 


3.  Telescope  and  Dome 


The  SOA  telescope  is  a  40  cm. 
(16  in.)  f/3.75  Paramount  Telescope  with  an 
open-framed  truss  and  German  equatorial 
mount  provided  by  Software  Bisque1, 
Golden,  Colorado  as  shown  in  Figure  9.  A 
commercial  Apogee  AP-7  CCD  (Figure  10) 
serves  as  the  imaging  sensor  for  SOA.  A 
two  stage  thermoelectric  cooler 
complements  the  CCD  camera.  Ash 
Manufacturing2  provided  the  3.2  meter  (10 
feet  6  inch)  dome,  including  base  ring, 
windscreen,  and  retractable  shutter 
displayed  in  Figure  1 1 .  Merlin  Controls3 
provided  the  automation  for  the  dome.  The 


dome  control  system  is  a  clever  design, 
using  a  Marine  battery  and  recharging  solar 


Figure  9  COTS  SOA  Telescope 


cell  to  power  the  dome  shutter  and  windscreen,  eliminating  the  need  for  slip  rings. 


A 


Light  Emitting  Device  and 
photodiode  on  the  ring 
motor  provide  the  home 
position  and  a  single 
communication  connection 
point  for  initiating  dome 
opening  and  closing.  The 
camera  shutter  triggered  a 
Datum  GPS  Receiver  and 
Timing  interface  card, 
providing  accurate  timing 
for  the  metric  data. 

The  high  desert 
climate  at  Edwards  AFB 
was  a  major  concern  during 


Figure  10  COTS  SOA  CCD  Imaging 


1  Software  Bisque,  912  Twelfth  Street,  Golden,  Colorado  80401-1114,  Telephone:  (800)  843-7599, 
http://www.bisque.com/. 

2  Ash  Manufacturing  Company,  PO  Box  31 2,  Plainfield,  IL  60544,  Telephone:  (815)  436-9403, 
http://www.ashdome.com/. 

3  Merlin  Controls  Corporation,  PO  Box  839,  Berthoud,  CO  80513,  Telephone:  (970)  227-9487, 
http://www.merlin.com/. 
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planning  for  SOA.  During  summer  days,  the  temperature  can  approach  120  °F,  while 
cooling  to  50-60  °F  during  the  night.  Since  the  SOA  is  autonomous,  its  control 
electronics  must  be  running  continuously,  so  electronic  overheating  during  the  day  was 
a  major  concern.  In  addition,  high  dome  interior  temperatures  at  the  start  of  the  night 
could  reduce  the  effectiveness  of  the  CCD  thermoelectric  cooler.  Consequently,  we 
installed  a  timer-activated  air  conditioner  in  the  dome  to  keep  the  interior  temperature  in 
the  70-80  °F  range  during  the  day.  The  timer  turned  off  the  air  conditioner  before 
sunset  to  minimize  temperature  gradients  during  the  night.  An  added  issue  was  that 
large  temperature  fluctuations  might  manifest  focus  changes  in  the  SOA  optics. 
However,  this  change  was  not  evident  during  the  test  period  once  we  fixed  the  focus 
adjustment  in  place. 


Figure  1 1  COTS  SOA  Dome 


4.  Telescope  Control  Computer 

The  telescope  control  computer  is  a  commercial  Pentium-based  PC  running 
Windows  NT  4.0.  The  telescope  and  camera  control  software  is  a  commercial  package 
called  TheSky  written  by  Software  Bisque.  TheSky  package  consists  of  several  inter¬ 
communicating  modules,  including: 

•  TheSky  application  itself  providing  telescope  and  dome  monitoring, 

•  CCDSoft  providing  CCD  camera  control, 

•  Autodome  interfacing  to  the  dome  control  system, 

•  GPStfp  interfacing  to  the  Datum  GPS  receiver, 

•  TPoint  providing  telescope  mount  modeling  for  accurate  pointing,  and 

•  Orchestrate  enabling  scripting  of  telescope  pointing,  satellite  tracking,  camera 
acquisition,  and  data  transfer. 
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The  telescope  control  computer  starts  the  Orchestrate  scripting  program  on  booting, 
permitting  autonomous  commanding  from  the  Data  Processing  Workstation  after  start¬ 
up. 


5.  Data  Processing  Workstation  (Odin) 

The  data  processing  workstation  called  Odin  is  a  Silicon  Graphics  Octane 
UNIX  workstation  running  IRIX  6.4.  The  data  processing  workstation  communicates 
with  the  prototype  scheduling  computer,  ODSP,  using  TCP  protocol  through  an  ITK 
Ethernet  router/dialer  and  Lucent  STU-III  encrypting  modem.  Odin  reports  metric 
observations  in  standard  B3  format  and  receives  tasking  for  the  next  series  of 
observations  from  the  ODSP  system  using  the  OC3F  scheduling  command  language. 
Once  Odin  receives  a  tasking  for  the  next  object  from  ODSP,  it  generates  an 
observation  script,  which  it  sends  to  the  telescope  control  computer.  The  data 
processing  workstation  monitors  weather  and  communication  status  until  the  telescope 
control  PC  transfers  an  image  data  file  in  FITS  format  using  FTP  protocol.  The  data 
processing  workstation  then  analyzes  the  FITS  image  file  to  determine  all  stars  in  the 
fields  as  well  as  detect  any  satellites  present.  The  detected  stars  are  matched  against 
the  nominal  positions  of  catalog  stars  from  the  Hubble  Guide  Star  Catalog.  From  this 
correlation,  the  equatorial  position,  orientation,  and  scale  of  the  image  are  determined  in 
mean  equator,  mean  equinox  of  J2000  for  the  topocentric  location  of  Edwards  AFB,  CA. 
Using  this  computed  transformation,  the  software  converts  pixel  positions  of  any 
detected  satellites  at  shutter  open  and  close  to  equatorial  coordinates.  It  applies  annual 
(stellar)  aberration  to  the  coordinates  of  the  satellite  to  account  for  light  time  travel 
variations  due  to  the  Earth’s  motion  around  the  Sun.  These  corrected  coordinates  are 
then  converted  to  B3  format  and  correlated  against  an  on-line  database  of  deep  space 
satellite  element  sets  using  correlation  software  provided  by  the  Space  Warfare  Center 
Analysis  and  Engineering  Division  (HQ  SWC/AE).  After  correlation,  the  data  processing 
workstation  transmits  the  tagged  metric  observations  to  ODSP  along  with  magnitude 
estimates. 


The  Odin  data  processing  system  also  has  two  additional  responsibilities. 
First,  Odin  monitors  the  time,  initiates  the  nightly  observations  at  the  beginning  of 
nautical  twilight  after  sunset,  with  the  Sun  12°  below  the  horizon,  and  terminates  at  the 
end  of  nautical  twilight  before  sunrise.  The  start-up  sequence  includes  activating 
TheSky  and  supporting  applications  through  an  Orchestrate  script  transmitted  to  the 
telescope  control  PC,  which  opens  the  dome  and  activates  the  thermoelectric  cooler  for 
the  CCD  camera.  In  addition,  as  part  of  the  start-up  procedure,  Odin  opens  a  TCP 
connection  to  the  ODSP  system  and  requests  tasking  for  the  first  3  objects.  The 
shutdown  sequence  includes  parking  the  telescope  in  a  nominal  position,  closing  the 
dome,  disconnecting  communications  with  the  CCD  camera,  and  finally,  rebooting  the 
telescope  control  PC  to  compensate  for  any  memory  leaks  in  Windows  NT.  Odin’s 
second  responsibility  is  to  communicate  with  the  weather  sensor,  Autonomous  Weather 
Protection  System  (AWPS)  and  initiate  a  shutdown  sequence  if  AWPS  reports  the 
presence  of  precipitation  or  winds  exceeding  a  user-defined  wind  speed,  which  was  set 
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at  30  mph.  If  Odin  detects  inclement  weather,  it  requires  30  minutes  of  dry  weather  and 
5  minutes  of  wind  speeds  below  30  mph.  before  reinitiating  the  start-up  sequence. 

6.  Autonomous  Weather  Protection  System  (AWPS) 

AWPS  provides  local  real-time  monitoring  of  meteorological,  environmental 
and  system  parameters  that  could  be  hazardous  to  an  optical  telescope.  AWPS 
primary  functions  are  to  monitor  meteorological  and  environmental  conditions,  monitor 
the  health  of  the  host  telescope  controlling  computer,  open  and  close  the  telescope 
enclosure  and  alert  personnel  if  a  hazardous  condition  exists  during  observing  periods. 
AWPS  in  effect  replaces  a  human  observer  with  a  machine.  Figure  12  shows  a  block 
diagram  of  AWPS. 


Figure12  AWPS  Block  Diagram 


AWPS  consists  of  two  parts;  tower  system  and  controller  system.  The  tower 
system  includes  the  meteorological  and  environmental  sensing  equipment,  3-m  tower, 
1.2-m  square  base,  2.5-m  mast  assembly,  and  support  items  (see  Figure  13).  The 
tower  system  is  co-located  with  the  telescope  enclosure  to  measure  local  weather 
conditions  and  is  external  to  the  controller  system.  For  the  SOA  demonstration,  the 
tower  system  was  about  15m  from  the  telescope  enclosure  and  30  m  from  the 
controller  system.  The  meteorological  and  environmental  sensing  equipment  includes 
an  optical  precipitation  detector,  wind  speed  sensor,  and  a  day/night  detector.  For  the 
SOA  demonstration,  we  mounted  a  GPS  antenna/receiver  on  the  right  mast  arm. 
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Figure13  SOA  Dome  Enclosure 
with  AWPS  Tower  System 


The  optical  precipitation  sensor  uses 
precipitation-induced  scintillation  as  the  detection 
method.  Falling  liquid  or  frozen  precipitation 
causes  beam  intensity  variations  in  the  infrared 
light  as  it  passes  through  the  beam.  These 
irregularities,  known  as  scintillation,  have 
characteristic  patterns,  which  the  sensor  detects 
and  converts  to  a  precipitation  rate.  The  detector 
has  a  liquid  precipitation  range  0.1  to  500  mm/hr 
(light  mist  to  heavy  downpour)  and  frozen 
precipitation  range  of  0.01  to  50  mm/hr  (water 
equivalent)  with  a  time  constant  of  10  seconds. 
For  the  SOA  demonstration,  the  sensor  data 
update  rate  was  once  per  minute. 

The  wind  speed  sensor  provides  low 
starting  threshold,  quick  response,  and  high 
accuracy  with  excellent  reliability  over  a  wide 
range  of  operating  conditions.  It  has  an 
operating  dynamic  range  of  0.44  to  44  m/s  (1  to 
100  mphs)  with  a  threshold  of  0.44  m/s. 

The  day/night  detector  senses  ambient 
light  using  a  photodiode  detector,  which  converts 
light  energy  into  an  electrical  current.  It  converts 


this  current  into  a  voltage  representing  the  light  energy  in  foot-candles.  A  comparator 
circuit  provides  a  switched  output  from  the  sensor  corresponding  to  the  sensed  daytime 


or  nighttime  condition.  It  reports  daytime  when  the  ambient  light  intensity  is  above  29 
lux  (2.7  foot-candles).  Nighttime  activation  occurs  when  the  ambient  light  intensity  falls 


below  7.5  lux  (0.7  foot-candles).  In  order  to  calculate  visibility  conditions,  this  sensor 
usually  connects  to  a  visibility  sensor  or  transmissometer  to  indicate  whether  it  should 


use  daytime  or  nighttime  calculations  in  determining  visibility. 
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Figure  14  AWPS  Mast  Assembly 


Figure  14  shows  a  close-up 
view  of  the  mast  assembly.  The 
optical  precipitation  detector  is  on  the 
left  side,  the  day/night  detector  is  the 
lower  middle,  and  the  wind  speed 
sensor  in  at  the  top  middle.  The  SOA 
sensor  system  GPS  antenna/receiver 
head  is  on  the  right  side. 

The  controller  system 
includes  a  MIT/LL  designed  data 
acquisition  system,  an  automatic 
voice/pager  dialer,  two  ASCII  display 
terminals,  120  cm  rack,  and  support 
items  (see  Figure  15).  The 
programmable  controller  consists  of  a 


Z180  microprocessor  running  at  18.432  MHz.  The  components  of  the  controller  fit  on  a 


single  printed  circuit  board  making  it  very  compact. 
The  controller  is  C-programmable.  Using  Dynamic  C 
eliminated  the  need  for  in-circuit  emulators,  logic 
analyzers,  and  software  simulators.  Programming 
the  controller  for  the  SOA  demonstration  required  a 
modest  400  SLOC  (source  lines  of  code). 

The  SOA  Data  Processing  Computer 
(DPC)  issues  an  ASCII  character  “A”  every  15  s  for 
heartbeat  monitoring  by  AWPS.  AWPS  replies  with  a 
70-character  ASCII  string.  The  ASCII  string  contains 
the  present  precipitation  condition,  instantaneous 
precipitation  rate,  total  precipitation  accumulation, 
wind  speed,  day  or  night  status,  AWPS  front-panel 
controller  status,  present  dome  shutter  position  and 
AWPS  condition  (“S”  for  safe,  “U”  for  unsafe).  The 
front-panel  controller  ASCII  status  string  included 
push  button  switches  for  enabling  or  disabling  an 
overall  alarm,  precipitation  alarm,  wind  speed  alarm, 
daylight  condition  alarm.  Additionally,  a  front  panel 
switch  can  enable  or  disable  the  voice/pager  dialer. 

In  an  ideal  installation,  AWPS  has  direct 
control  over  the  dome  and  can  close  the  telescope 
shelter  without  control  computer  intervention. 
Normally,  this  would  allow  closing  the  dome  if  the 


Figure15  AWPS  Controller 
System 


DPC  stopped  functioning  (as  detected  by  lack  of  the 
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“A”  heartbeat).  Due  to  interface  limitations  with  the  Merlin  Controls  dome  system, 
AWPS  had  no  direct  control  over  the  telescope  dome  during  the  SOA  demonstration 
and  had  to  rely  on  the  SOA  DPC  for  telescope  safety. 

7.  Secure  Communications 

Establishing  secure  point-to-point  communications  between  the  central 
dynamic  scheduler  and  the  sensor  sites  was  a  significant  challenge.  The  OC3F  non- 
GEODSS  interface  message  set  and  message  content  is  a  low  bandwidth  link.  Due  to 
the  classification  level  of  some  space  surveillance  data  and  deep  space  element  sets, 
the  link  must  provide  appropriate  security  at  the  SECRET  level.  Both  the  SOA 
demonstration  and  the  future  non-GEODSS  interface  to  OC3F  require  establishment  of 
TCP/IP  connectivity  at  the  ISO-7498  network/service  layer.5  The  actual  messages  that 
implement  remote  dynamic  scheduling  and  data  delivery  for  the  sensor  exchange  at  the 
higher,  application  layer  of  the  interface  and  function  independent  of  the  specific 
implementation  of  the  network  and  transport  layer.  This  level  of  connectivity  also 
support  familiar  networking  tools  such  as  remote  login  (rlogin),  telnet,  and  file  transfer 
protocol  (ftp). 

MIT/LL  studied  several  different  options  to  establish  secure  network 
connectivity  between  sensor  sites.  Table  1  summarizes  the  options  considered.  Each 
method  listed  implements  full  network  connectivity,  but  with  different  levels  of 
performance,  initial  cost,  and  operating  cost. 

The  first  option  uses  a  Lucent  Secure  Data  Device  (SDD)  1910  for  data 
encryption  and  a  dial-on-demand  network  router.  The  router  converts  the  network  traffic 
at  the  site  into  a  serialized  data  stream  using  the  popular  PPP  protocol.  A  SDD-1910  or 
STU-3  modem  can  then  transmit  the  traffic  to  the  remote  end.  When  the  dial-on- 
demand  router  detects  network  traffic  addressed  for  the  remote  site,  it  dials  the  modem, 
establishes  the  remote  connection,  and  transmits  the  data.  The  router  at  the  far  end 
receives  the  data  and  places  it  on  its  local  network.  The  router  hangs  up  the  telephone 
line  after  a  pre-configured  duration  of  inactivity  on  the  link  (typically  5-10  minutes).  This 
approach  has  the  lowest  initial  cost  and  requires  the  least  infrastructure  and  lead-time  to 
establish.  For  these  reasons,  we  chose  this  method  for  the  SOA  demonstration.  The 
availability  of  secure  modems  limits  the  data  transfer  rate,  which  is  slow  in  comparison 
to  commercial  unsecure  modems.  Additionally,  telephone  long  distance  charges  can  be 
substantial. 


4  Even  if  the  sensor  was  to  be  scheduled  only  unclassified  objects,  the  data  must  be  processed  and 
protected  at  the  SECRET  level  due  to  the  possibility  of  inadvertently  tracking  an  uncorrelated  target 
(UCT). 

The  network/service  layer  is  defined  in  ISO-7498  OSI-RM  layered  network  architecture.  This  layer 
equivalent  to  the  interface  level  established  by  a  PC  with  dial-up  networking  under  Windows  95/98. 
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Option 

Equipment 

Infrastructure 

Comments 

Dial-on-Demand  w/ 
secure  modem 

SDD-1910  or  STU-III 
Dial-on-Demand 

Router 

Voice  telephone  line 

Selected  for  SOA. 

Current  TOS  backup  capability. 

Lowest  initial  cost  and  infrastructure 
requirements. 

High  operational  cost 

Leased  Line 

KIV-7  or  KG 

Network  Router 
CSU/DSU 

Dedicated  line 

Current  TOS  capability 

Typically  higher  performance  and  reliability 
Long  lead  time  for  dedicated  line  install. 

High  operational  cost 

Network  Encryption 
System  (NES) 

NES 

“Internet" 

Connection 

Highest  performance. 

Allows  establishing  multi-point  secure  private 
network. 

High  initial  cost. 

Uses  existing  UNCLASS  internet  connectivity. 
Low  operating  cost. 

Vulnerable  to  denial-of-service  attack. 

Potential  firewall  penetration  issues. 

Dial-on-Demand  w / 
NES  and  unsecure 
modem 

COTS  modem 

NES 

Network  Router 

Voice  telephone  line 

Allows  used  of  higher  speed  COTS  modems. 
NES  provides  data  security. 

High  initial  cost  of  NES. 

High  operation  cost. 

Viable  operational  backup  for  denial-of- 
service  attack  against  NES  option. 

Table  1  Secure  Communications  Options 


The  second  option  uses  traditional  leased  line  service  and  KG-84,  KG-194,  or 
KIV-7  serial  encryption  devices.  Network  routers  serialize  the  network  traffic  for  the 
encryption  devices  and  a  traditional  CSU/DSU  interfaces  with  the  leased  line.  TOS 
uses  this  approach.  The  initial  equipment  cost  is  comparable  to  option  one,  but  the 
initial  installation  of  a  leased  line  is  required.  Operational  costs  are  generally  lower  for  a 
leased  line  when  connect  times  exceed  several  hours  per  day. 

The  third  option  is  to  use  pre-existing  unclassified  Internet  connectivity 
between  the  sensor  site  and  the  central  site  using  Motorola  Network  Encryption 
Systems  (NES)  technology.  The  NES  encrypts  data  for  secure  transmission  across 
unsecured  wide  area  networks  (WANs)  or  across  a  secure  WAN  such  as  SIPRNET. 

The  NES  is  a  Type  I  Controlled  Cryptographic  Item  (CCI),  endorsed  by  the  National 
Security  Agency  (NSA),  under  the  Commercial  COMSEC  Endorsement  Program 
(CCEP).  The  NES  can  process  data  up  to  Top  Secret/SCI  and  uses  the  same 
"FIREFLY"  algorithm  used  in  the  STU-III  telephones.  The  most  attractive  feature  of  the 
NES  solution  is  the  use  of  existing  network  connectivity,  which  a  host  base  or  other 
organization  usually  maintains.  However,  we  must  consider  several  operational  issues. 
First,  operational  sensors  using  public  networks  for  communication  become  vulnerable 
to  “denial-of-service”  attacks  to  the  network.  Second,  local  network  administrators  are 
generally  not  required  to  respond  to  the  operational  requirements  of  the  Space 
Surveillance  Network.  We  can  reasonably  address  both  of  these  problems  by 
combining  the  NES  option  with  a  backup  dial-up  capability  outline  in  option  4. 
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The  last  method  is  a  variation  of  the  same  basic  scheme  outlined  in  option 
one.  Here,  we  use  NES  for  data  security,  but  a  dial-up  connection  supplies  physical 
connectivity.  The  advantage  of  using  the  NES  as  the  encryption  device  instead  of  the 
SDD-1910  in  option  1  is  that  now  the  modem  is  on  the  “black”  or  unclassified  side. 

Now,  a  high  performance  COTS  modem  can  be  used,  improving  both  bandwidth  and 
noise  immunity.  The  initial  hardware  is  relatively  expensive  compared  to  option  one. 
This  architecture  offers  a  viable  secondary  capability  to  augment  the  NES  solution 
above  should  the  public  network  be  down  or  subjected  to  a  denial-of-service  attack. 

Figure  16  shows  the  dial-on-demand  system  integrated  for  the  SOA 
demonstration  period.  The  technical  solution  provided  on-demand  network  connectivity 
between  the  ODSP  and  SOA  sensor  at  a  bandwidth  of  14400  baud.  During  the 
integration  period,  we  discovered  the  vendor  had  discontinued  the  originally  specified 
NEC  Dr.  Bond  router  and  we  had  to  identify,  evaluate,  and  integrate  a  new  network 
router  with  dial-on-demand  for  the  demonstration.  We  ultimately  selected  the  Netblazer 
LS  2-PT  manufactured  by  ITK  International.  The  Netblazer  is  ideal  for  the  application 
as  it  supports  both  dial-up  and  dedicated  line,  and  can  use  dial-up  as  backup  support 
for  the  leased  line. 


Figure  16  Block  Diagram  of  SOA  Communications  System 


3.  RESULTS 


A.  Objective  Satisfaction 


Objective  1 :  SOA  successfully  demonstrated  remote,  autonomous  collection  and 
reporting  of  metric  data  on  deep  space  objects.  During  the  demonstration  period  of  28 
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July  through  14  August  1998  the  SOA  system  produced  nearly  6,000  metric  observation 
without  any  human  intervention  at  Edwards  AFB.  SOA  reported  the  data  in  proper 
format  to  the  ETS.  Unfortunately,  the  time  required  (~  6  months)  to  gain  approval  for 
transmission  of  the  observations  into  CMAS  precluded  operational  reporting  of  the  data. 

Objective  2:  SOA  demonstrated  the  value  added  of  geographically  dispersed 
sensors  to  the  SSN.  Because  ODSP  could  not  report  the  observations  collected  at 
Edwards  AFB  to  1  CACS  and  CMAS,  we  could  not  directly  measure  the  impact  to 
dispersed  sensors.  However,  during  the  18  day  demonstration,  the  Socorro  GEODSS 
site  was  weathered  out  2  days  and  the  Maui  GEODSS  site  was  weathered  out  1  day. 
The  SOA  sensor  could  have  tracked  and  reported  observations  on  many  of  their  tasked 
objects  and  minimized  the  weather  outage  impact  on  the  SSN. 

B.  Summary  of  Results 

1.  AFRL  Results  Summary 

Table  2  summarizes  the  observation  throughput  and  acquisition  rate  for 
several  nights  during  the  pretest  period  and  over  the  two-week  test  period.  The 
columns  show: 

•  the  day  of  year  (Julian  Date), 

•  observation  time  period  in  hours  for  statistics  (Hrs), 

•  the  number  of  raw  counts,  (This  is  the  number  of  attempts  for  the  night,  minus 
the  number  of  W  events,  plus  the  number  of  additional  acquisitions.  (#  cnt)) 

•  the  number  of  images  that  had  less  than  6  stars  detected  indicating  red  weather 
or  dome  blockage  (W), 

•  the  number  of  images  where  the  catalog  star  matching  failed  due  to  either  invalid 
equatorial  coordinates  in  the  header  or  insufficient  number  of  catalog  stars 
detected  (U),  (This  number  indicates  red  weather  or  red  equipment.) 

•  the  number  of  image  series  where  the  tasked  object  was  not  detected  (N), 

•  the  number  of  image  series  where  the  tasked  object  was  detected  but  less  the  5 
metrics  marks  (partial  acquisition)  were  generated  (P), 

•  the  number  of  image  series  where  the  tasked  object  was  detected  and  5  or  more 
metric  marks  (full  acquisition)  were  generated  (Acq),  (This  number  includes  the 
number  of  additional  acquisitions.) 

•  the  number  of  additional  objects  detected  within  an  image,  excluding  the  tasked 
object  (AddAcq), 
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Day 

Hrs 

#cnt 

W 

U 

N 

P 

Acq 

Add  Acq 

191 

0.81 

31 

0 

2 

11 

3 

15 

4 

195 

147 

1 

21 

54 

21 

51 

10 

Tf 

156 

8 

26 

70 

11 

49 

8 

■HOB 

105 

0 

12 

11 

60 

14 

209 

156 

4 

18 

25 

82 

47 

WEEM 

7.5 

3 

26 

82 

123 

28 

mm 

3.7 

1 

17 

38 

52 

12 

213 

7.4 

292 

2 

75 

53 

139 

38 

216 

3.7 

128 

3 

16 

19 

60 

17 

217 

7.3 

225 

1 

31 

99 

17 

78 

19 

218 

7.7 

271 

4 

35 

126 

31 

79 

14 

219 

7.6 

158 

88 

50 

84 

1 

23 

1 

223 

7.8 

201 

54 

33 

101 

22 

45 

11 

224 

7.8 

238 

38 

35 

108 

18 

21 

225 

7.8 

269 

30 

25 

128 

24 

14 

226 

6.1 

109 

81 

25 

45 

9 

30 

8 

Total 

90.41 

2894 

318 

397 

1101 

341 

1055 

266 

Table  2  Observation  Throughput  and  Acquisition  Rate  by  Day 


One  of  the  benefits  of  this  system  is  its  use  of  astrometry,  where  the  position 
of  the  stars  determines  the  position  of  the  satellites,  sometimes  called  in-frame  metrics. 
Not  only  is  the  accuracy  of  the  observations  better  than  with  a  system  that  uses  mount 
encoders,  but  if  multiple  satellites  appear  in  the  image,  the  positions  of  all  of  the 
satellites  can  be  determined  simultaneously.  The  current  GEODSS  system  does  not 
use  astrometry  and  therefore  does  not  get  the  advantage  of  these  serendipitous 
collects. 


The  result  of  the  SOA  approach  is  there  were  a  number  of  images  where 
multiple  satellites  appeared  in  the  image.  SOA  reported  all  of  those  satellites.  AFRL 
performed  an  analysis  on  the  “bonus”  satellites,  and  most  of  them  were  on  the  tasking 
list.  Because  of  this,  and  because  any  satellite  observation  obtained  would  be  useful  to 
1  CACS,  these  bonus  satellites  were  included  in  the  track  count. 

There  are  some  instances  where  SOA  obtained  partial  tracks  on  satellites. 
This  is  not  the  case  for  satellites  tracked  in  sidereal  mode.  For  satellites  tracked  in 
stare  mode,  however,  where  three  images  of  the  satellite  were  required,  there  were 
occasions  when  only  one  or  two  of  these  images  included  the  entire  satellite  track. 
Although  these  images  did  not  satisfy  the  requirement  of  five  satellite  observations  with 
ten  second  intervals  between  observations,  the  information  provided  is  still  of  benefit  to 
1  CACS,  and  can  be  used  to  update  the  catalog.  Because  of  this,  we  counted  partial 
tracks  as  part  of  the  system  performance.  These  partial  tracks  are  also  included  in  the 
results. 
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Based  on  the  discussion  later  in  the  report,  the  throughput  of  the  system,  if 
operated  in  a  mode  consistent  with  what  was  learned  during  this  test,  is  between  40  and 
45  satellite  attempts  per  hour.  The  actual  throughput  during  the  demonstration  was 
somewhat  lower  because  of  an  easily  solved  inefficient  coupling  between  the  scheduler 
and  SOA. 

Table  3  is  a  brief  chronology  of  the  operational  status  of  the  SOA  system: 


28  Jul  98 

Day  209 

The  system  collected  metric  data  only  during  the  second  half  of  the  night  after 
the  system  re-booted. 

29  Jul  98 

Day  210 

The  system  collected  metric  data  all  night. 

30  Jul  98 

Day  211 

The  telephone  line  at  Edwards  Air  Force  Base  was  not  plugged  into  the  STU; 
thus,  the  system  could  not  communicate  with  the  ODSP. 

31  Jul  98 

Day  212 

The  system  collected  metric  data  for  the  first  half  of  the  night.  After  the  re-boot  in 
the  middle  of  the  night,  there  was  a  failure  with  the  following  error  message:  “PC 
Time-out  waiting  for  FITS  files." 

1  Aug  98 

Day  213 

The  system  collected  metric  data  all  night. 

IB 

llglggg 

The  communication  equipment  failed  because  it  was  not  plugged  into  the  UPS. 

We  had  to  re-initialize  the  equipment. 

3  Aug  98 

Day  215 

The  SOA  system  at  Edwards  Air  Force  Base  could  not  communicate  with  the 
ODSP  system  because  the  STU  key  was  not  plugged  in  at  ETS. 

4  Aug  98 

Day  216 

The  system  collected  metric  data  for  the  first  half  of  the  night.  After  the  re-boot  in 
the  middle  of  the  night,  there  was  a  failure  with  the  following  error  message:  “PC 
Time-out  waiting  for  FITS  files." 

5  Aug  98 

Day  217 

The  system  collected  metric  data  all  night  however,  the  sky  map  that  ODSP  uses 
to  schedule  was  not  completed  before  the  SOA  system  connected.  Thus,  the 
number  objects  available  for  the  SOA  was  limited. 

6  Aug  98 

Day  218 

The  system  collected  metric  data  all  night. 

7  Aug  98 

Day  219 

The  system  collected  metric  data  all  night. 

8  Aug  98 

Day  220 

The  SOA  system  at  Edwards  Air  Force  Base  could  not  communicate  with  the 
ODSP  system  because  the  crew  at  ETS  was  not  available. 

9  Aug  98 

Day  221 

The  SOA  system  at  Edwards  Air  Force  Base  could  not  communicate  with  the 
ODSP  system  because  the  crew  at  ETS  was  not  available. 

1 0  Aug  98 

Day  222 

The  SOA  system  at  Edwards  Air  Force  Base  could  not  communicate  with  the 
ODSP  system  because  all  the  allowable  sockets  were  utilized  from  trying  to 
connect  the  previous  2  nights. 

mm 

The  system  collected  metric  data  all  night.  However,  there  was  red  weather  at 
the  beginning  of  the  night. 

Ml 

The  system  collected  metric  data  all  night.  However,  there  was  red  weather  at 
the  beginning  of  the  night. 

The  system  collected  metric  data  all  night.  However,  it  was  raining  until  UT  5:32 
p.m. 

14  Aug  98 

Day  226 

The  system  collected  metric  data  all  night.  However,  there  was  red  weather  at 
the  beginning  of  the  night 

TABLE  3  Nightly  Operational  Status  During  Autonomous  Test  Period 


As  the  chronological  data  shows,  the  availability  and  operational  status  of  the 
autonomous  SOA  telescope  and  data  analysis  system  was  high.  The  failure  of  metric 
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data  collection  was  due  to  the  “human  in  the  loop”  aspects  of  the  SOA  demonstration 
where  the  ODSP  system  required  a  person  to  bring  up  the  system  daily.  The 
chronological  data  also  demonstrates  that  the  communication  equipment  may  not  be 
the  best  choice  due  to  the  reliability  and  the  security  aspects  of  needing  a  “man  in  the 
loop." 


2.  MIT/LL  Results  Summary 

Table  4  provides  a  night  by  night  statistical  summary  of  the  performance  of 
the  SOA  system  during  the  18-day  demonstration  period.  We  derived  these  statistics 
from  the  operational  ODSP  logs  using  automated  report  generation  software  at  the 
ETS.  The  statistics  given  in  Table  4  differ  by  those  given  in  Section  1  in  three  important 
ways.  First,  the  number  of  successful  acquisitions  is  limited  to  only  that  data  which  was 
correctly  correlated  against  either  the  originally  scheduled  object  or  another  tasked 
object  (the  quality  of  the  correlator  used  at  the  ETS  was  superior  to  that  used  by  AFRL). 
Second,  a  successful  acquisition  must  contain  at  least  as  many  observations  as  the 
original  tasking  suffix  indicated  (partial  tracks  are  indicated  as  Miss  X).  Third, 
observations  received  that  are  more  than  tasking,  or  have  no  tasking  are  not  counted  as 
a  successful  acquisitions  except  in  the  Total  Obs  and  Extra  Obs  columns.  In  addition, 
we  deleted  days  in  which  the  ETS  received  no  data. 

During  the  18-day  test  period,  the  SOA  system  produced  nearly  6000  metric 
observations.  This  represents  an  average  observation  rate  of  a  76.35  obs/hr.  The  SOA 
system  had  a  mean  acquisition  rate  of  6.48  tracks/hr  when  we  count  only  successful 
acquisitions  that  are  applicable  directly  against  sensor  tasking.  Approximately  1 8% 
sensor  attempts  resulted  in  the  successful  collection  of  a  complete  metric  track  that  are 
applicable  against  tasking.  Acquisition  rate  peaked  as  high  as  30%  on  98:216,  during 
which  the  sensor  collected  44  successful  tracks  in  3.7  hours  of  operation  (11.9 
tracks/hr).  A  comparison  of  objects/site  of  baseline  GEODSS,  refurbished  GEODSS, 
and  SOA  is  included  in  Table  1 1 . 
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Day  of  Year 
(1998) 

Ops  Time  (hr) 

Attempts 

Extra  Attempts 

Acquire 

Acquisition 

Rate  (trk/hr) 

Miss 

Miss  (W) 

Miss  (N) 

Miss  (U) 

Miss  (X) 

Total  Obs 

Extra  Obs 

Retag  Obs 

209 

3.4 

109 

60 

29 

8.5 

66 

4 

23 

18 

21 

458 

313 

166 

210 

7.5 

265 

58 

69 

9.2 

156 

3 

85 

26 

42 

867 

522 

64 

212 

3.7 

152 

11 

37 

10.0 

86 

1 

40 

17 

28 

368 

183 

35 

213 

7.4 

278 

90 

69 

9.3 

140 

2 

80 

25 

33 

987 

642 

88 

216 

wm a 

147 

6 

44 

11.9 

82 

3 

34 

16 

29 

398 

WmBSk 

28 

217 

7.3 

■on 

46 

6.3 

159 

1 

104 

31 

23 

501 

■QO 

26 

Kl 

7.7 

276 

29 

46 

6.0 

206 

4 

132 

35 

35 

525 

8 

219 

7.6 

256 

7 

16 

2.1 

226 

88 

86 

51 

1 

140 

60 

0 

223 

7.8 

260 

16 

24 

3.1 

219 

HI 

105 

33 

27 

335 

215 

10 

224 

7.8 

272“ 

32 

42 

54 

206 

112 

35 

21 

525 

315 

58 

225 

7.8 

309 

24 

63 

8.1 

223 

30 

139 

25 

29 

635 

320 

33 

226 

•  6.1 

202 

8 

19 

3.1 

166 

81 

46 

HI 

12 

201 

■Hul 

10 

Total 

77.8 

wmm 

367 

504 

83 

1935 

■cllltli 

986 

■ritEll 

5940 

■E232I 

526 

1 .  Ops.  Time:  Reported  operational  time  from  Reference. 

2.  Attempts:  Number  of  SOA  sensor  scheduling  instances  during  operational  period. 

3.  Extra  Attempts:  Number  of  unsolicited  or  serendipitous  responses  from  the  sensor  (miss  or  data). 

4.  Acquire:  Number  of  successful  acquisitions  that  were  consistent  with  the  original  tasking  suffix  and  properly 
correlated  against  the  scheduled  object  or  another  tasked  satellite. 

5.  Acquisition  Rate:  Number  of  successful  acquisitions  divided  by  operational  time  in  hours. 

6.  Miss:  Total  number  of  reported  unsuccessful  acquisitions  or  partial  acquisitions. 

7.  Miss  (W):  Total  number  of  unsuccessful  acquisitions  attributed  to  weather  by  the  SOA  sensor. 

8.  Miss  (N):  Total  number  of  unsuccessful  acquisitions  attributed  to  non-weather  causes  by  the  sensor. 

9.  Miss  (U):  Total  number  of  unsuccessful  acquisitions  due  to  image  header  coordinate  error  in  the  SOA  sensor. 

10.  Miss  (X):  Total  number  of  incomplete  tracks  reported  by  the  SOA  sensor. 

1 1 .  Total  Obs:  Total  number  of  metric  observations  received  from  the  SOA  sensor. 

12.  Extra  Obs:  Total  number  of  metric  observations  received  for  which  there  was  not  applicable  tasking. 

13.  Retag  Obs:  Total  number  of  metric  observations  retagged  to  a  different  satellite  number  or  UCT  by  the  ODSP 
correlator. 


Table  4.  SOA  Sensor  Performance  Summary 


C.  Detailed  Results 

The  Appendix  contains  a  night-by-night  evaluation  of  the  system  performance. 
The  following  sections  discuss  results  and  recommendations  on  various  aspects  of  the 
demonstration. 


1.  Synchronous  Scheduling  and  Data  Processing/Delivery 

One  of  the  fundamental  assumptions  of  the  ODSP  design  is  that  participating 
sensors  are  providing  verification  of  successful  acquisition  and  metric  data  in  near  real¬ 
time.  From  the  perspective  of  the  centralized  scheduler,  this  is  critical  as  it  dynamically 
modifies  future  scheduling  decisions  based  on  the  success  or  failure  of  previous 
attempts.  From  the  sensor  perspective,  if  the  sensor  is  unable  to  process  acquired 
frame  sets  into  metric  observations  at  least  as  fast  as  it  observes  new  objects,  a 
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backlog  of  unprocessed  data  accumulates  at  the  site.  Worse,  the  centralized  scheduler 
is  forced  to  either  “commit”  an  increasing  number  of  objects  to  the  site  with  no 
assurance  the  objects  have  been  tracked  or  to  redundantly  schedule  these  objects  to 
another  site. 


Figure  17  shows  the 
metric  data  delivery  time  for  the 
SOA  sensor  during  the  18-day 
test  period.  Data  delivery  time  is 
the  elapsed  time  from  the  initial 
scheduling  instance  until  the  PC 
delivers  data  to  the  ODSP.  A 
detailed  review  of  the  logs 
shows  that  under  optimal 
conditions,  SOA  typically 
delivered  data  in  4-5  minutes. 


Figure  18  shows  the 
start-up  sequence  and 
communication  between  the 
telescope  control  PC,  data 
processing  workstation,  and  ODSP  scheduler.  The  SOA  telescope  and  CCD  has  the 
ability  to  download  the  image  of  the  current  object,  while  slewing  to  the  next  object.  The 
scripts  executed  by  the  telescope  control  PC  illustrate  this  need  for  multiple  tasked 
objects.  To  maximize  the  throughput  of  the  SOA  sensor,  Odin  requests  three  tasked 
objects  (A-C)  before  transmitting  the  metrics  of  object  A.  However,  this  delay  between 
object  tasking  and  reporting  had  important  ramifications  on  the  throughput  of  the  SOA 
system  during  testing  as  it  interacted  with  the  ODSP  scheduler. 

When  a  satellite  is  scheduled  by  ODSP,  the  object  (or  more  specifically,  the 
tasking  associated  with  the  object)  is  “committed”  to  the  sensor  for  a  specific  period. 
During  this  interval,  ODSP  will  not  schedule  the  object  to  another  sensor  in  the  network. 
Once  the  sensor  responds  to  the  scheduling  with  either  a  miss  code  or  data,  the  object 
is  no  longer  committed  and  ODSP  may  again  schedule  it  to  any  sensor  should  any 
tasking  remain  on  the  object.  ODSP  developers  imposed  the  time  limit  to  ensure  that  it 
eventually  reschedules  an  object  to  other  sensors  should  the  original  sensor  fail  to 
respond  within  a  reasonable  time.  For  the  SOA  demonstration,  we  set  this  time  limit  to 
5.0  minutes.  However,  a  review  of  the  ODSP  operational  logs  shows  that  a  time  of 
approximately  20  minutes  would  have  been  more  appropriate. 
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Figure  18  SOA  Start-up  and  Operations  Sequence 

Despite  mitigation  strategies,  the  late  delivery  of  data  to  the  ODSP  had  some 
unanticipated  side  effects  when  ODSP  scheduled  the  SOA  sensor  to  track  a  satellite  in 
a  cluster  of  other  tasked  satellites.  Normally,  the  ODSP  schedules  a  single  object.  If 
the  sensor  is  capable  of  acquiring  data  on  multiple  objects  in  the  field  of  view,  ODSP 
receives  this  data  as  “serendipitous”  data  and  applies  it  appropriately  against  tasking. 
However,  due  to  delayed  data  delivery,  the  ODSP  did  not  know  that  SOA  had  tracked 
nearby  objects  until  several  minutes  after  the  next  scheduling  instance.  Consequently, 
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SOA  would  multiply  track  cluster  members,  artificially  increasing  the  throughput  of  the 
sensor  and  providing  redundant  data  to  the  SCO. 

In  order  for  ODSP  to  integrate  successfully  sensors  with  slower  metric 
delivery  times,  it  could  take  one  of  three  actions.  First,  an  appropriate  “commit  time” 
must  be  determined  for  the  capabilities  of  each  sensor.  For  the  SOA  demonstration,  we 
used  5  minutes.  However,  as  the  above  analysis  shows,  20  minutes  would  have  been 
better.  This  will  ensure  other  sensors  are  not  scheduled  to  track  objects  which  the 
augmenting  sensors  are  still  “working  on.”  Second,  all  objects  within  the  field  of  view 
and  tracking  capabilities  of  the  sensor  should  be  committed  to  the  sensor  by  the 
scheduler.  Although  this  would  add  computational  complexity  to  the  OC3F  dynamic 
scheduling  algorithms,  it  would  prevent  the  redundant  cluster  tracking  discussed  above. 
Third,  and  potentially  a  simpler  solution  is  to  alter  slightly  the  SOA  software  to 
compensate  for  this  delay. 

2.  Throughput 

The  throughput  of  the  system,  if  operated  in  a  mode  consistent  with  what  was 
learned  during  this  test,  is  between  40  and  45  satellite  attempts  per  hour.  The  numbers 
were  somewhat  lower  during  the  demonstration  due  in  large  part  to  the  unoptimized 
interaction  of  the  telescope  and  the  scheduling  software. 

Looking  at  two  days,  day  217  and  day  225,  one  can  see  the  effect  of 
optimization.  Figure  19  shows  the  azimuth  position  as  a  function  of  time  for  those  days. 
Notice  that  what  is  shown  in  most  of  these  plots,  regardless  of  day,  is  that  the  telescope 
is  being  sent  back  and  forth,  often  from  low  on  the  horizon  in  one  direction  to  low  on  the 
horizon  in  the  opposite  direction.  This  is  due  to  the  lag  time  associated  with  the 
scheduling  process  and  the  telescope  motion.  The  result  is  that  the  telescope  is 
spending  an  inordinate  amount  of  time  moving  back  and  forth.  It  becomes  much  worse 
when  the  telescope  moves  back  and  forth  across  the  meridian  (the  line  dividing  East 
from  West).  Because  of  the  design  of  the  mount,  the  telescope  must  move  to  the 
South,  cross  the  meridian,  and  then  move  back  North. 


Time  (hours) 


Day  217  Day  225 

FIGURE  19  Throughput  Comparison  between  Day  217  and  Day  225 
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Day  21 7  is  an  example  of  a  bad  case.  Not  only  is  the  range  of  telescope 
motion  quite  large,  but  it  continually  crosses  back  and  forth  across  the  meridian. 

Indeed,  if  one  looks  at  the  throughput  for  day  217,  it  is  only  28  satellite  attempts  per 
hour.  The  only  time  during  this  day  where  the  mount  operates  in  the  desired  mode  is 
from  about  0645  hrs  to  0730  hours.  During  this  period,  the  throughput  is  44  satellite 
attempts  per  hour. 

Day  225  is  a  good  case,  when  the  throughput  is  40  satellites  per  hour. 
Although  there  is  some  “ringing”  in  the  motion  of  the  telescope  in  azimuth,  it  is  not  very 
large,  and  seldom  crosses  the  meridian.  The  throughput  for  the  last  half  of  the  night  is 
45  satellites  per  hour.  The  throughput  is  at  its  worst  (29  satellite  attempts  per  hour) 
during  the  third  hour  (0600-0700),  when  the  telescope  is  moving  back  and  forth  across 
the  meridian. 

It  is  important  to  note  that  this  is  a  very  easy  problem  to  solve.  We  can  solve 
the  problem  either  at  the  scheduler,  or  at  the  SOA  controller.  The  problem  arises  from 
time  lag  between  satellite  tasking  and  reporting.  One  solution  is  for  the  SOA  to  request 
a  satellite,  not  based  on  the  current  position  of  the  telescope,  but  either  at  the  desired 
position  of  the  telescope  (good  phase  angle),  or  the  position  where  the  telescope  will  be 
when  it's  ready  for  the  next  satellite.  Either  case  would  better  optimize  the  telescope 
motion  thus  increasing  throughput. 

If  the  system  were  in  operation  today,  with  this  excessive  mount  motion 
reduced,  its  throughput  should  be  in  the  range  of  40  to  45  satellite  attempts  per  hour,  as 
demonstrated  on  both  of  the  days  analyzed. 

3.  Satellite  Tracking  Mode 

For  the  SOA  demonstration,  MIT/LL  added  an  additional  descriptive  field  to 
the  satellite  database  in  ODSP  to  indicate  the  proper  tracking  mode  for  the  satellite. 

The  two-valued  field  indicated  that  the  object  was  best  observed  in  rate  track  (stare 
tracking)  mode  (satellite  stationary),  or  streak  detect  (sidereal  tracking)  mode 
(background  stars  stationary).  In  stare  tracking,  the  telescope  position  is  fixed,  causing 
the  stars  to  appear  as  streaks  moving  at  sidereal  rate  and  along  the  equatorial  axis, 
while  geostationary  satellites  appear  as  point  sources  and  other  deep  space  objects 
appear  as  streaks  at  arbitrary  angles  and  rates.  In  sidereal  tracking  mode,  the 
telescope  moves  to  compensate  for  the  rotation  of  the  Earth,  so  stars  appear  as  point 
sources  whereas  satellites  generally  appear  as  streaks. 

Both  tracking  modes  have  their  advantages  and  disadvantages.  For  dim  or 
flashing  near-geostationary  objects,  stare  tracking  mode  allows  the  satellite  irradiance 
to  dwell  and  accumulate  on  just  a  few  pixels,  providing  a  higher  signal  to  noise  ratio  and 
improving  the  probability  for  detection.  The  disadvantage  of  stare  tracking  is  that  the 
streaking  stars  tend  to  clutter  the  image  background,  increasing  the  opportunity  for 
bright  stars  streaks  to  overlap  onto  dim  objects,  and  may  often  require  multiple  images 
to  achieve  the  requirement  of  5  metric  marks.  Sidereal  tracking  assures  that  satellites 
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will  appear  as  distinct  streaks  against  a  background  of  point-like  stellar  objects.  By 
opening  the  shutter  for  20  seconds,  closing  it  for  10  seconds,  and  opening  it  for  10 
seconds  before  downloading  the  images  from  the  CCD,  the  velocity  vector  for  the 
satellite  is  uniquely  determined  and  the  endpoints  of  each  streak  along  with  the  center 
of  the  20  second  streak  provides  5  metric  marks  separated  by  10  seconds  each.  The 
sidereal  tracking  disadvantage  is  the  corollary  to  stare  mode’s  advantage;  the  satellite 
irradiance  is  smeared  along  a  range  of  pixels  at  sidereal  rates  or  higher. 

Figure  20  shows  the  display  output  of  processing  a  satellite  in  sidereal  mode. 
The  stars  highlighted  with  circles  indicate  stars  matched  with  catalog  star  positions. 

The  square  marks  indicate  computed  satellite  metric  positions,  which  the  PC  transmits 
to  the  ODSP  system.  Figure  21  shows  the  detection  of  two  satellites  during  ballistic 
tracking.  Although  one  satellite  point  image  is  in  a  star  streak,  the  image  processing 
software  is  still  able  to  detect  the  satellite  object. 


FIGURE  20  Satellite  image  processing  on  Odin  from  sidereal  tracking 
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FIGURE  21  Satellite  image  processing  on  Odin  from  stare  tracking 

In  pre-deployment  and  site  integration  tests,  Maui,  HI  and  Edwards  AFB,  CA 
observed  a  large  portion  of  unclassified  satellites.  A  visual  observer  selected  the 
tracking  mode  for  each  satellite  based  on  the  brightness  and  temporal  characteristics  of 
the  satellite  and  stored  in  a  satellite  information  database.  Although  a  significant 
number  of  satellites  were  observed,  the  list  of  satellites  with  optimized  tracking 
strategies  was  not  complete,  in  particular,  excluding  a  large  fraction  of  classified 
satellites.  Continued  supervised  testing  can  extend  this  list  and  improve  acquisition 
rates. 


4.  Minimum  and  Maximum  Tracking  Rate 

Because  of  the  narrow  field-of-view  (FOV)  of  the  telescope,  one-half  degree, 
MIT/LL  added  a  minimum  and  maximum  tracking  rate  screen  to  ODSP.  For  the 
demonstration,  this  prevented  scheduling  of  any  objects  with  an  angular  rate  less  than  4 
arcsec/sec  or  greater  than  24  arcsec/sec.  Figure  22  shows  the  angular  velocity 
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distribution  of  the  visible  deep  space  population6  at  a  particular  instant.  The  vertical 
reference  lines  indicated  the  4  arcsec/sec  and  24  arcsec/sec  scheduling  screens.  Only 
six  of  the  visible  objects  had  angular  rates  below  the  4  arcsec/sec  minimum  screen.  Of 
these,  three  were  highly  eccentric  super-synchronous  objects.  However,  109  objects 
(21%  of  deep  space  objects)  had  angular  velocities  greater  than  the  24  arcsec/sec 
maximum  screen.  This  is  a  significant  fraction  of  deep  space  objects  that  were 
unavailable  to  the  sensor.  A  telescope  with  a  1 -degree  FOV  would  double  the  tracking 
rate  from  that  used  in  the  demonstration  (1 /2-degree  FOV)  and  increase  to  48 
arcsec/sec  the  tracking  rate  limit  of  the  system.  This  increase  in  FOV  would  add 
approximately  85  more  objects  and  decrease  the  percentage  of  objects  that  had  angular 
velocities  greater  than  the  new  48  arcsec/sec  maximum  screen  to  5%  of  deep  space 
objects.  We  recommend  that  the  FOV  of  the  telescope  be  one  of  the  design 
considerations  in  acquiring  a  SOA-like  system.  An  alternative  to  a  wider  FOV  is  to 
observe  these  objects  at  other  times,  when  the  angular  velocity  are  within  the 
capabilities  of  the  sensor,  or  schedule  the  objects  to  other  sensors. 
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Figure  22  Angular  Velocity  Distribution  of  Deep  Space  Satellites 


5.  Adjustment  of  Existing  Scheduling  Weights  and  Screens 

One  of  the  essential  features  of  the  centralized  scheduler  is  the  ability  to  set 
sensor  specific  values  of  the  various  weights  and  screens  for  different  sensors.  This 
feature  can  both  implement  different  scheduling  philosophies  for  different  sites  and 
adjust  sensor  scheduling  for  special  capabilities  or  limitations  of  particular  sensors.  For 
example,  by  adjusting  the  tasking  priority  weights,  it  can  dedicate  certain  sensors  to 
high  priority  objects. 


6  Here,  deep  space  is  defined  as  any  object  having  a  period  longer  than  225  minutes. 
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For  the  SOA  demonstration,  MIT/LL  adjusted  several  of  the  previously 
existing  (TOS)  ODSP  scheduling  weights  and  screen  values  to  the  telescope 
performance  characteristics. 

Table  5  shows  some  of  the  key  scheduling  parameters  used  for  the  SOA 
demonstration  period  taken  from  the  ODSP  operational  logs  on  98:223.  For 
comparison,  we  also  show  the  currently  used  TOS  scheduling. 


Scheduling  Criterion 

SOA 

Sensor 

TOS 

Comment 

Element  Set  Age 

-2 

1 

This  unusual  setting  caused  satellites  with  younger  element 
sets  to  be  scheduled  first. 

Telescope  Slew  Angle 

6 

1 

This  strongly  weighted  slew  distance,  which  minimized  slew 
distance  between  successive  tracks. 

Dome  Slew  Angle 

2 

1 

Elevation  Rate 

2 

1 

Elevation 

2 

1 

Solar  Phase  Angle 

4 

1 

Phase  angle  strongly  effects  satellite  brightness.  This  weight 
improved  the  likelihood  that  satellites  were  only  scheduled  at 
favorable  phase  angles. 

Galactic  Latitude 

■ 

No 

screen 

The  SOA  star  field  recognition  algorithms  would  run  more 
slowly  with  high  background  star  density.  This  preventing 
scheduling  of  objects  against  the  Milky  Way  where  star 
density  was  high. 

Tasking  Category  1 

0 

36 

For  SOA  all  higher  weighting  of  higher  tasking  categories 
was  disabled. 

Tasking  Category  2 

0 

24 

Tasking  Category  3 

0 

14 

Tasking  Category  4 

0 

8 

Tasking  Category  5 

0 

0 

Table  5  SOA  Demonstration  Scheduling  Criteria 


Note  that  there  was  confusion  between  MIT/LL,  the  Space  Battlelab,  and 
AFRL  on  the  exact  operation  of  the  scheduler.  The  Space  Battlelab  requested  MIT/LL 
apply  filters  based  on  the  following  criteria: 

Element  set  age:  <14  days 
Phase  Angle:  <60  degrees 
No  changes  to  Tasking  Priority 

However,  the  scheduler  could  not  put  in  upper  limits,  instead  it  could  only 
optimize  for  minimum  phase  angle  and  element  set  age.  In  addition,  ODSP's  Tasking 
Priority  weights  were  off.  We  will  discuss  the  unfortunate  effect  on  the  demonstration  of 
this  misunderstanding  in  further  detail  in  the  subsequent  sections. 
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a.  Element  Set  Age 

Element  set  age  is  a 
controversial  scheduling  criteria. 

Although  the  GEODSS  A- 
Specification  requires  its  use  as  a 
scheduling  criterion,  it  does  not 
specify  exactly  how  to  use  the 
criterion.  From  the  sensors  point  of 
view,  element  set  age  is  often  used 
as  an  indicator  of  element  set  quality 
(older  element  sets  have  greater 
error).7  In  theory,  a  sensor  site 
should  not  have  weight  by  element 
set  age  at  all  and  rely  completely  on 
the  tasking  category  assigned  to  the 
object  by  the  1  CACS.  Thus,  when  a 
sensor  uses  element  set  age  as  a  scheduling  or  mission  planning  criterion,  it  is  used 
only  to  “break  ties”  between  tasking  at  the  same  category.  Generally,  ODSP  gives  the 
older  element  sets  greater  priority,  using  the  logic  that  1  CACS  needs  data  more 
desperately  on  these  objects.  The  current  implementation  of  the  ODSP  uses  a  simple 
linear  weighting  function  for  element  set  age. 

However,  during  the  SOA  demonstration  we  anticipated  that  the  narrow 
field  of  view  of  the  SOA  sensor  would  require  younger  element  sets  to  increase  the 
probability  of  successful  acquisition.  The  desire  was  to  have  element  sets  age  less  than 
14  days  old  (a  filter).  Unfortunately,  the  ODSP  could  only  minimize  the  age  of  the 
element  sets.  Figure  23  shows  the  dramatic  effect  of  this  criterion  to  the  overall 
scheduling  of  the  system.  This  created  the  strong  tendency  for  the  ODSP  to  schedule 
young  element  sets  to  the  SOA  sensor. 

Fortunately,  there  were  a  large  number  of  satellites  tracked  with  element 
set  ages  greater  than  4  days,  Figure  24  shows  consistent  acquisition  rates  for  element 
set  ages  out  to  12  days  old.  Considering  the  SOA  acquisition  did  not  show  dramatic 
dependence  on  element  set  age,  it  should  not  be  a  major  consideration  in  scheduling 
objects  to  SOA. 
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Figure  23  Histogram  of  Field  Element  Set  Age  at 
Scheduling 


7  Since  1  CACS  issues  new  field  element  sets  only  when  they  degrade  beyond  a  particular  value  from  the 
element  set  maintained  internally  at  SCC,  this  indicator  is  not  necessarily  correct.  Nonetheless,  as  a 
general  rule,  the  older  field  element  sets  will  indeed  have  higher  error  at  the  current  epoch. 
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Figure  24  Acquisition  rate  as  a  function  of  element  set  age 
b.  Phase  Angle 

Solar  phase  angle8 
strongly  effects  the  observed 
brightness  of  satellites  when  viewed 
from  the  Earth.  Typically,  GEODSS 
and  other  optical  sensors  attempt  to 
observe  fainter  satellites  at  favorable 
phase  angles  when  they  are  easier  to 
detect.  For  geosynchronous 
satellites,  the  most  favorable  phase 
angles  typically  occur  shortly  before 
the  satellite  enters  Earth  shadow. 

Figure  26  shows  the  effect  of  phase 
angle  on  generic  shaped  objects. 

Here,  it  represents  the  phase  in 
terms  of  the  satellite  brightness  in 
visual  magnitudes  relative  to  the 
diffusely  reflecting  cylinder.  As  can  be  seen  from  the  graph,  typical  diffusely  reflecting 
objects  show  little  decrease  in  brightness  for  phase  angles  less  than  20-30°.  However, 
for  phase  angles  approaching  90°,  satellite  brightness  decreases  by  1 .2  to  1 .4  visual 
magnitudes.  For  typical  geosynchronous  satellites,  this  can  easily  be  the  difference  in  a 
successful  detection  or  missing  the  object,  even  for  a  1 -meter  class  GEODSS 
telescope.  Chronically  tracking  a  particular  satellite  at  a  near-optimal  phase  angle  has  a 
subtle  and  detrimental  effect  on  element  set  quality,  particularly  when  the  same  site 
usually  tracks  the  satellite.  Historically,  this  has  been  a  problem  with  sensor  data 
collected  by  the  GEODSS  network.  For  this  reason,  Unified  Instruction  Ul  10-40 
specifically  encourages  sites  to  “strive  to  sample  different  parts  of  the  orbit  on  different 


8  In  this  report,  phase  angle  refers  to  the  Earth/Sun  angle  as  observed  from  the  satellite. 
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Figure  26  Phase  Functions  of  Generic  Objects 
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attempts."  Additionally,  1  CACS  tasks  objects  to  multiple  sites  in  an  attempt  to  gain 
sampling  along  different  parts  of  the  orbit.  In  the  future,  the  OC3F  will  specifically 
schedule  objects  to  obtain  this  sampling  without  having  to  schedule  multiple  sites. 

The  desire  was  to 
have  phase  angles  less  than  60 
degrees  (a  filter).  Unfortunately, 
the  ODSP  could  only  minimize 
the  phase  angle.  Figure  27 
shows  the  distribution  by  phase 
angle  of  all  scheduling  instances 
during  the  18-day  demonstration. 
As  can  be  seen,  ODSP 
scheduled  nearly  all  of  the 
satellites  when  the  phase  angle 
was  less  than  approximately  229. 
Under  these  conditions,  the 
diffuse  magnitude  of  the  satellite 
very  minimally  degrades. 

SOA’s  acquisition  rate  remained  high  between  solar  phase  angles  of  10 
and  60  degrees.  Moreover,  intelligent  scheduling  can  task  these  ranges  of  solar  phase 
for  both  sides  of  the  Earth’s  shadow  for  high  elevation  deep  space  objects.  Therefore, 
one  can  measure  some  50  to  100  degrees  of  the  orbit  of  the  satellite. 

Phase  angle  should  still  be  a  consideration  in  tasking  a  SOA  sensor. 
However,  a  maximum  angle,  approximately  60  degrees,  should  be  set.  There  is  no 
need  to  optimize  for  minimum  phase  angle. 

c.  Telescope  and  Dome  Slew  Distance 

Telescope  and  dome  slew  times  are  primary  factors  increasing  the  time 
for  a  sensor  to  track  a  particular  satellite.  For  the  purposes  of  efficiency,  GEODSS, 
TOS,  and  other  optical  space  surveillance  systems  generally  minimize  the  slew  distance 
between  subsequent  satellites.  This  increases  system  throughput  by  decreasing  the 
amount  of  time  the  system  spends  waiting  for  the  dome  and  telescope  to  slew  to  the 
correct  position.  Unfortunately,  operational  requirements  may  require  long  slew 
distances,  particularly  to  satisfy  tasking  of  category  1  and  2  objects  early  in  the  evening. 
Consequently,  most  telescopes  used  for  space  surveillance  application  have  high  speed 
mount  and  dome  systems.  For  example,  the  GEODSS  telescope  is  able  to  track  at 
rates  up  to  2  degrees/sec  and  slew  at  rates  up  to  1 0  degrees/sec. 
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Figure  27  Phase  Angle  Distribution  of  Scheduled 
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The  telescope 
mount  used  for  the 
demonstration  was  a  “German 
Equatorial”  type.  One  limiting 
physical  characteristic  of  this 
mount  is  that  motion  from  one 
side  of  the  meridian  to  the  other 
requires  a  180°  rotation  in  the 
equatorial  axis,  as  well  as  some 
motion  in  declination.  Most  low 
cost,  commercial,  astronomical 
telescopes,  including  the 
Paramount  used  in  SOA,  have 
limited  maximum  slew  rate, 
generally  around  4-5  “/second, 
requiring  30  seconds  to  2 
minutes  to  move  between  the  hemispheres  about  the  meridian.  MIT/LL  designed  the 
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Figure  29  Distribution  of  Slew  Distance 


ODSP  scheduler  to  work  with  the  fast-slewing  GEODSS  telescope  on  a  forked 
equatorial  mount,  which  do  not  experience  this  meridian-crossing  constraint. 
Consequently,  when  ODSP  uses  the  weighted  selection  criteria  such  as  minimal  mount 
motion  for  SOA,  the  angle  computed  for  a  meridian  crossing  does  not  represent  the  true 
angle  the  SOA  telescope  must  slew.  As  can  be  seen  from  Figure  29,  the  scheduler  was 
effective  in  minimizing  the  slew  distance  for  the  sensor.  Of  the  2743  scheduling 
instances  during  the  18-day  demonstration,  48%  required  a  slew  distance  of  less  than 
6°,  70%  less  than  10°,  and  82%  less  than  15°.  However,  this  did  not  necessarily 
minimize  the  time  required  to  slew  the  telescope. 


Currently,  the  ODSP  schedules  uses  a  very  simple  linear  cost  function  for 
both  telescope  and  dome  slew  distance.  In  future  demonstrations,  one  could  easily 
develop  a  more  complex  cost  function  to  represent  the  unusually  long  slew  times  when 
the  telescope  must  cross  the  local  meridian.  An  alternative  approach,  without 
modification  to  ODSP,  is  to  modify  the  Odin  executive  process  to  select  only  tasking  in 
the  east  (azimuth  <  180°)  until  local  midnight  (0800  UT)  and  then  select  only  tasking  in 
the  west  (azimuth  >  180°)  after  midnight.  Odin  would  reject  all  other  tasking  with  a 
miscode  ‘X’.  We  tested  neither  of  these  options  during  the  demonstration. 
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d.  Satellite  Category 

1  CACS  assigns  every  satellite  tasked  by  the  SCC  for  metric  observation 
a  category  and  suffix  to  define  the  priority  and  data  requirement  for  the  satellite.  The 
tasking  category  (specified  by  an  integer  between  1  and  5)  defines  the  priority  for  taking 
observations  and  resolves  tracking  conflicts  when  two  or  more  satellites  are  in  the 

coverage  of  the  sensor  at  the 
same  time.  The  SPADOC 
tasker  uses  the  element  set 
quality  and  age  to  determine 
the  tasking  category.  In 
general,  as  element  set  age 
increases  or  element  set  quality 
deteriorates  the  tasking 
category  will  increase.  By 
definition,  Category  1  is  special 
events  of  the  highest  priority. 
The  optical  sensors  use 
Category  2  for  both  special 
events  and  high  priority  routine 
tasking.  All  remaining  lower 
priority  tasking  use  Categories 
3-5.  Figure  30  shows  a  profile 
of  typical  GEODSS  tasking  (actually,  this  is  tasking  for  the  Socorro  GEODSS  Site  for 
Day  21 1 ,  during  the  SOA  demonstration).  Approximately  18%  of  the  tasking  is  category 
2,  32%  category  3,  and  50%  category  4. 

For  typical  operations,  tasking  category  is  the  strongest  weighting 
function.  The  category  weight  is  strongly  weighted  towards  the  higher  categories. 
Because  of  the  category  weight  differential's  design,  nearly  all  satellites  tasked  at  a 
higher  category  will  generate  a  scheduler  figure  of  merit  greater  than  all  other  satellites 
of  lower  category.  Unfortunately,  for  the  demonstration,  the  category  weighting  was 
disabled.  Thus,  ODSP  scheduled  all  tasked  satellites  equally,  regardless  of  category. 

With  the  majority  of  the  AFSPC  tasking  for  routinely  observed  satellites  at 
category  4,  the  presumption  was  SOA  would  not  perform  as  well  for  satellites  tasked  at 
category  2  or  category  3.  Figure  30  shows  that  although  almost  half  of  the  objects 
observed  were  category  4,  satellites  with  a  higher  priority  tasking  of  category  2  actually 
had  a  higher  acquisition  rate.  Category  5  objects  generally  have  well  known  orbits, 
resulting  in  the  high  80%  acquisition  rate  recorded.  Consequently,  SOA  shows  good 
acquisition  capability  independent  of  satellite  tasking  category.  Moreover,  during  this 
observation  period  the  Maui  GEODSS  spent  70%  of  the  time  going  after  category  3  and 
4  objects. 
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Figure  30  Typical  GEODSS  Tasking  Profile 
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Figure  31  Acquisition  Rate  vs.  Tasking  Category 


The  interesting  result  in  Figure  31  is  the  lower  acquisition  rate  seen  for 
category  3  satellites.  The  average  optical  brightness  measured  for  category  3  and 
category  4  satellites  acquired  were  both  about  13.1  magnitudes.  Therefore,  SOA's 
category  3  failed  acquisitions  are  probably  not  due  to  SOA’s  detection  sensitivity.  In 
examining  a  variety  of  measured  parameters,  the  major  difference  between  category  3 
objects  from  category  2  and  4  objects  is  the  tracking  mode  selected.  Table  6  shows  the 
observation  count  for  each  category  for  both  the  sidereal  and  stare  tracking  modes. 


■sSESQI 

Sidereal 

527 

918 

1778 

103 

Stare 

1039 

452 

1611 

10 

Table  6  Observation  Count  per  Category 

As  evident  from  the  table,  category  3  objects  were  observed  twice  as  often 
in  sidereal  mode,  while  conversely,  category  2  objects  where  observed  twice  as  often  in 
stare  mode.  Stare  mode  acquires  3  images  each  with  10-second  exposures,  while 
sidereal  model  acquires  a  single  image  with  an  exposure  time  of  40  seconds.  Stare 
mode  tracks  closely  with  deep  space  objects,  while  sidereal  mode  causes  the  satellite 
image  to  streak  as  the  telescope  tracks  the  stars.  Consequently,  stare  mode  has  a 
higher  probability  of  acquisition  for  objects  offset  from  its  predicted  position.  By 
increasing  the  selection  of  stare  mode  tracking  for  category  3  objects,  a  higher 
acquisition  rate  should  be  possible. 
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6.  Centralized  Correlation 
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We  demonstrated  the 

utility  of  centralized  correlation 

throughout  the  18-day 

demonstration.  Of  the  5940 

metric  observations  received  by 

ODSP,  526  (8.9%)  were 

retagged  by  the  correlator. 

Figure  32  schematically  shows 

one  particular  example,  taken 

from  98:209.  Here,  ODSP 

scheduled  the  SOA  sensor  to 

track  a  geosynchronous  object. 

In  response  to  the  scheduling, 

the  SOA  sensor  replied  with  6 

««  _  .  ~  ...  *  observations,  all  labeled  with 

Figure  32  Schematic  of  Sensor  Misstag  ,he  same  scc  number  Rgure 

32  shows  the  observations  with  the  relative  right  ascension  and  declination  in  arc 
seconds.  It  annotates  the  relative  time  next  to  each  observation.  However,  the 
correlator  associated  the  lower  four  observations  with  a  deep  space  UCT  and  only  the 
upper  two  observations  with  the  originally  scheduled  object.  Only  the  two  appropriately 
associated  observations  were  applied  against  tasking,  resulting  in  a  missed  attempt.  In 
a  full  network  demonstration,  ODSP  would  have  rescheduled  this  object,  perhaps  to  a 
different  sensor,  to  satisfy  the  tasking. 
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This  is  an  example  where  AFRL  data  would  indicate  an  “acquired”  object,  but 
MIT/LL  would  not.  This  is  a  limitation  on  the  correlator  used  during  the  SOA 
demonstration,  not  on  the  augmentation  concept. 


7.  Dome  Blocking  at  the  Meridian 


An  infrequent  effect  of  the  SOA  German  Equatorial  mount  and  dome  occurs 
during  small  angular  motions  across  the  meridian.  During  this  period,  TheSky  software 
commanding  the  telescope  will  try  to  “cheat"  and  not  rotate  the  equatorial  axis  by  180°, 
but  slew  the  declination  axis  to  look  over  the  mount.  The  problem  arises  in  that  the 
dome,  following  the  telescope  motion,  assumes  that  the  telescope  has  done  the  180° 
equatorial  rotation  and  positions  the  shutter  opening  accordingly.  Unfortunately,  for 
some  motions  within  3°  of  the  meridian,  the  dome  will  block  the  field  of  view  of  the 
telescope.  This  occurrence  is  infrequent  and  will  occur  1-2  times  during  nightly 
operations.  The  data  processing  workstation  interprets  this  dome  blockage  as  weather 
and  transmits  a  W  miscode  to  ODSP.  The  software  vendor  for  TheSky,  Software 
Bisque  is  aware  of  the  problem  and  will  fix  it  in  a  future  version  of  the  software. 


Unclassified 


37 


SOA  After  Initiative  Report 


Unclassified 


8.  Telescope  Control  Computer  Restart 

During  site  integration,  AFRL  discovered  a  memory  leak  in  the  dome  control 
process,  AutoDome,  running  in  the  telescope  control  computer.  This  periodic  memory 
leak  eventually  consumed  all  the  system  memory  after  five  hours  of  operation.  The 
vendor,  Software  Bisque,  plans  to  correct  this  error  in  a  future  version  of  TheSky 
software  package.  To  work  around  this  problem,  the  data  processing  workstation,  Odin, 
shuts  down  the  telescope  and  dome  and  reboots  the  telescope  control  computer  after 
four  hours  of  operation,  resetting  memory  allocation. 

There  are  two  disadvantages  to  this  solution.  First,  the  restart  sequence 
consumed  30  minutes  of  observing  time.  The  second  disadvantage  had,  in  some 
cases,  a  more  prolonged  influence  on  performance.  The  SOA  system  originally 
operated  from  sunset  to  sunrise  with  the  starting  position  of  the  telescope  always  fixed 
at  an  azimuth  of  90°  and  an  elevation  of  30°.  When  AFRL  incorporated  this  restart 
sequence  into  the  Odin  software,  the  changes  necessary  to  eliminate  this  “hard-coded” 
starting  angle  were  too  extensive  to  accomplish  prior  testing.  Consequently,  after  the 
telescope  control  computer  restarted  near  local  midnight,  it  requested  tasking  from  the 
ODSP  scheduler  with  the  telescope  reported  at  a  corresponding  azimuth  of  90°  and 
elevation  of  30°.  At  0800  UT,  satellites  in  this  reported  position  in  the  sky  had  poor 
phase  angle  and  therefore,  reduced  probability  of  acquisition.  We  assumed  ODSP 
would  select  a  more  optimal  set  of  objects,  largely  ignoring  the  reported  telescope 
pointing.  In  many  cases,  this  was  true,  but  in  some  cases  such  as  Day  209  (28  Jul  98 
UT),  this  effect,  coupled  with  ODSP  tasking  and  reporting  delay,  lasted  for  several 
hours.  A  better  solution  would  have  been  to  ignore  the  current  telescope  position  and 
request  tasking  from  ODSP  using  coordinates  corresponding  to  brightest  satellite 
illumination  and  minimum  phase  angle. 

9.  Prior  Observation  Reporting 

At  nautical  twilight  before  sunrise,  the  SOA  system  performs  an  orderly 
sequence  of  shutdown  events.  Odin  sends  a  script  to  the  telescope  control  computer  to 
park  the  telescope,  close  the  dome,  and  shutdown  the  PC  control  software,  such  as 
TheSky.  However,  due  to  the  stacking  of  tasking  to  the  telescope  control  computer  the 
telescope  control  computer  may  still  image  and  transmit  a  few  remaining  observations 
before  shutdown.  Depending  on  the  sequence  of  events,  Odin  may  not  process  these 
remaining  image  files  until  the  start  of  the  next  night’s  operation.  The  issues  arises  is 
similar  to  the  problem  described  in  Section  3C8,  the  reported  telescope  azimuth  and 
elevation  position  for  the  tasking  the  fourth  object  may  be  in  the  west,  where  the  phase 
angle  for  satellite  illumination  is  large  and  the  tasked  object  is  dim.  As  in  Section  3C8, 
the  assumptions,  consequences,  and  solutions  are  the  same.  The  ODSP  scheduler 
was  expected  to  largely  ignore  the  reported  telescope  angle,  but  in  some  cases,  such 
as  Day  217  (5  Aug  98  UT),  the  tasking  resulted  in  numerous  meridian  crossings 
reducing  throughput,  and  poor  phase  angle  reducing  successful  satellite  acquisitions. 
The  trivial  solution  to  this  is  reporting  a  “nominal”  telescope-pointing  angle,  while 
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ignoring  reported  metric  angles,  which  would  have  eliminated  this  performance 
degradation. 

10.  Element  Set  Age  and  Elevation  Tasking  Errors 

In  developing  satellite  tracking  capability  in  their  software,  Software  Bisque 
noted  that  tracking  satellites  with  very  old  element  set  ages  had  a  very  low  probability  of 
acquisition.  Therefore,  tasking  a  satellite  with  an  element  set  age  greater  than  45  days, 
results  in  a  scripting  error  on  the  telescope  control  computer  and  termination  of  the 
selected  tasked  object  without  the  generation  of  any  image  files.  Due  to  balance 
considerations  and  physical  limits  of  the  mount,  the  SOA  telescope  also  had  a  hard 
restriction  to  remain  above  20°  elevation.  Tasking  below  20°  also  results  in  a  scripting 
error  and  no  image  file  generation.  We  synchronized  the  telescope  control  computer 
and  Odin  with  script  and  image  file  transmission.  For  each  script  file  created  and 
transmitted,  Odin  waits  to  receive  an  appropriate  image  file  from  the  CCD  camera.  With 
scripting  errors,  this  synchronization  is  broken. 

In  interfacing  with  the  ODSP  scheduler,  Odin  assumed  that  tasking  a 
satellite  with  element  set  age  greater  than  45  days  would  never  happen.  However,  in 
actuality,  the  range  specification  for  element  set  age  is  not  bounded,  but  serves  only  to 
adjust  weighting  factors.  In  the  case  of  tasking  elevation,  although  ODSP  does 
eliminate  tasking  below  this  elevation  limit,  since  there  is  a  delay  between  ODSP 
tasking  and  actual  observation,  SOA  may  exceed  this  lower  elevation  limit  for  non¬ 
geostationary  satellites. 

To  alleviate  this  hurdle  to  continuous,  autonomous  operation,  AFRL  added  a 
watchdog  timer  to  the  Odin  process  waiting  for  image  file  transfer.  If  more  than  10 
minutes  elapsed  since  last  image  file  transfer,  SOA  requested  new  tasking  from  ODSP, 
generated  a  new  script  file,  and  the  process  reset  to  wait  for  the  next  image.  With  50  to 
55  seconds  to  reconnect  the  STU  III  encrypting  modem  and  router,  a  total  time  of 
00:10:50  to  00:10:55  was  lost  between  observations.  This  errant  tasking  will  appear  in 
two  successive  tasking  scripts  and  result  in  two  successive  watchdog  time-outs, 
generating  a  total  reduction  of  operation  time  of  00:21 :40  to  00:21 :50.  This  watchdog 
process  added  to  Odin  not  only  recovered  from  these  tasking  errors,  but  also  eliminated 
any  unforeseen  obstacles  to  autonomous  operation.  Watchdog  time-outs  were  noted 
on  Day  210  (29  Jul  98  UT),  Day  213  (1  Aug  98  UT),  and  Day  216  (4  Aug  98  UT). 

11.  System  Accuracy 

The  accuracy  of  the  observations  provided  by  the  SOA  system  are 
adequate  to  support  the  SSN. 

HQ  SWC/AE  analyzed  observations  made  with  the  telescope  in  Maui.  In 
February  1 997  they  reported  the  observations  ". . .  are  certainly  "as  good  or  better"  than 
GEODSS  . . .  Your  use  of  inframe  metrics  has  the  potential  to  provide  data  up  to  5  times 
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more  accurate  than  GEODSS."  SWC/AE  did  not  have  the  truth  data  available  to  judge 
absolute  accuracy9. 

AFRL/VS  analyzed  similar  telescope  observations  and  concluded  the 
system  has  . .  demonstrated  the  ability  to  produce  topocentric  right  ascension  and 
declination  observations  of  geosynchronous  satellites  with  noise  levels  under  two 
arcseconds10  (one  standard  deviations)." 

12.  Advanced  Weather  Protection  System 

The  SOA  version  of  AWPS  went  through  developmental  test  and  evaluation 
(DT&E)  at  ETS  for  150  hours  before  delivery  to  Edwards  AFB.  The  meteorological 
conditions  during  ETS  DT&E  had  no  hazardous  conditions  fortesting;  so,  MIT/LL 
simulated  hazardous  conditions.  The  functions  not  tested  were  frozen  precipitation  and 
blowing  snow  or  dust.  All  tested  functions  of  AWPS  performed  as  expected. 

MIT/LL  integrated  AWPS  into  the  SOA  Sensor  System  at  Edwards  AFB  on 
June  23, 1998.  All  functions  of  AWPS  performed  nominally  when  interfaced  into  the 
data  processing  computer.  The  wind  speed  hazard  threshold  parameter  was  modified 
for  Edwards  AFB  environment.  Maximum  wind  speed  was  set  at  35  mph  with  an 
averaging  time  constant  of  10  seconds  for  gusting  winds.  The  data  processing 
computer  watchdog  timer  constant  was  set  at  1 5  seconds.  The  second,  dome  alarm 
time  constant  was  set  to  240  seconds.  AWPS  uses  this  constant  by  AWPS  to  alert 
personnel  via  the  automatic  voice/pager  should  confirmation  of  dome  closure  not  occur. 

13.  Communications  System 

For  the  purposes  of  the  SOA  demonstration,  the  dial-on-demand 
communications  suite  performed  satisfactorily.  The  technical  solution  allowed  the  rapid 
integration  of  the  system  without  concern  for  the  long  lead  times  and  high  cost  of 
dedicated  leased  lines.  Although  there  were  some  problems  during  the  demonstration 
with  the  routers  “hanging  up”  after  long  periods  of  inactivity,  one  can  easily  address  this 
by  increasing  the  inactivity  timeout  parameter  in  the  router  configuration. 

For  a  long-term  demonstration  or  operational  deployment  of  autonomous 
sites,  the  operational  cost  of  the  dial-on-demand  solution  would  be  significant. 

Therefore,  for  an  operational  deployment,  a  leased  line  is  recommended  if  pre-existing 
network  connectivity  is  not  available.  We  recommend  a  Network  Encryption  System  for 
deployments  where  pre-existing  network  connectivity  is  available,  augmented  by  dial- 
on-demand  if  the  system  is  critical  to  operational  readiness. 


9  Reference  e-mail  sent  from  Mr.  Robert  Morris  to  Mr.  John  Africano  and  Mr.  Paul  Kervin  on  20  Feb  97 
titled  Analysis  of  Raven  Data 

10  Reference  Wallace,  S.,  Sabol,  C.,  "Use  of  the  Raven  Optical  Sensor  for  Deep  Space  Orbit 
Determination,"  AAS/AIAA  Astrodynamics  Specialist  Conference,  Sun  Valley,  Idaho,  August  4-7, 1997, 
AAS  97-705 
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14.  Security  Considerations 

Although  the  SOA  demonstration  was  autonomous,  many  questions  remain 
concerning  the  operational  implementation  of  unattended  space  surveillance  sensors. 
Specifically,  maintaining  adequate  data  and  physical  security  pose  a  significant 
challenge  at  unmanned  sites.  Potentially,  one  could  deploy  a  system  with  integrated 
strongboxes  and  alarm  systems  for  cryptographic  equipment.  Another  alternative  is  to 
deploy  only  at  locations  where  manned  security  already  exists. 

15.  RED  vs.  YELLOW  vs.  GREEN  Ops  Status 

We  based  the  codes  reported  by  SOA  to  the  ODSP  on  a  predicted 
performance  of  the  system.  Therefore,  we  made  the  decision  to  define  red  weather  as 
those  periods  where  the  number  of  detected  stars  in  the  field  of  view  was  less  than  5. 
Subsequent  analysis  indicates  that  a  more  meaningful  number  would  have  been  around 
12.  Consequently,  some  of  the  data  sent  to  the  surrogate  as  U  codes  should 
legitimately  been  classified  as  W  codes.  This  had  dramatic  consequences  during  night 
219,  for  example.  During  the  last  4  hours  of  the  night,  the  dome  malfunctioned,  so  that 
the  dome  obscured  the  stars.  During  this  period,  SOA  sent  84  W  codes  and  36  U 
codes  to  the  surrogate.  It  is  obvious  that,  with  the  proper  definition  of  red  weather,  all  of 
those  codes  should  have  been  W  codes.  This  is  true  in  general:  the  U  codes  define 
either  red  weather  or  red  equipment.  The  large  number  of  U  codes  sent  to  the 
surrogate  is  an  artifact  of  the  way  the  data  was  processed,  not  a  true  reflection  of  the 
system  performance.  If  we  treat  the  U  codes  as  indicative  of  green  conditions,  the 
following  becomes  the  number  of  hours  of  green  time  for  each  night. 


Day 

Green  time  (hrs) 

209 

3.3 

7.4 

3.7 

7.3 

216 

3.6 

217 

7.3 

218 

7.6 

219 

4.9 

224 

5.8 

225 

5.8 

Table  7  Green  Time  per  Day 


As  noted  above,  if  we  compare  the  data  for  night  21 9  shown  in  the  above 
table  to  the  detailed  data  for  that  night,  the  artificial  nature  of  this  approach  becomes 
obvious. 


The  following  table  indicates  the  performance,  broken  down  by  day,  of  the 
SOA  system  running  autonomously  during  the  18-day  period.  For  each  day,  the  data  of 
interest  is: 
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•  the  “Green  time”,  that  is,  the  time  the  system  was  up  and  running  in  green  weather 
and  with  no  equipment  problems 

•  the  number  of  satellites  for  which  observations  were  attempted 

•  the  average  throughput  for  satellite  attempts 

•  the  number  of  satellite  tracks  (4  or  more  observations/track)  which  were  sent  to  the 
ODSP. 


Day 

Green  time 
(hrs) 

Attempts 

Throughput 

(#/hr) 

Tasked 

Acqs 

Addl  Acqs 

Total 

Tracks 

209 

2.74 

109 

33 

66 

47 

113 

mm 

6.64 

249 

34 

141 

28 

169 

■na 

3.15 

119 

32 

64 

12 

76 

6.62 

254 

35 

154 

38 

192 

216 

3.08 

111 

31 

62 

17 

79 

217 

6.17 

206 

28 

76 

19 

95 

218 

6.55 

257 

34 

96 

14 

110 

219 

3.32 

157 

32 

23 

1 

24 

224 

5.27 

91 

33 

74 

21 

95 

225 

5.4 

233 

40 

98 

14 

112 

Total 

49.14 

1886 

33 

854 

211 

1065 

TABLE  8  Testing  Summary  during  Green  Time 


A  random  check  of  the  additional  acquisitions  that  SOA  reported  to  the 
ODSP  indicated  that  all  of  the  additional  acquisitions  were  on  the  tasking  list  for  that 
night,  so  it  is  appropriate  to  take  credit  for  those  tracks. 

In  addition,  there  were  a  number  of  periods  of  yellow  weather.  SOA  defines 
Yellow  weather  on  an  hourly  basis.  Yellow  weather  hours  are  those  hours  where  a 
significant  number  of  images  have  fewer  than  80%-matched  stars.  The  primary 
difference  between  green  and  yellow  conditions  is  that,  not  surprisingly,  the  number  of 
tracks  goes  down  significantly  compared  to  the  number  of  attempts. 


Day 

Yellow  time  (hrs) 

Attempts 

Tasked  Acqs 

Addl  Acqs 

5.02 

190 

31 

56 

11 

67 

Wife 1 

0.24 

26 

30 

0 

0 

0 

mm 

0.54 

22 

24 

4 

0 

4 

wsm 

2.55 

101 

30 

31 

8 

39 

BBl 

8.50 

30 

91 

19 

110 

TABLE  9  Testing  Summary  during  Yellow  Time 


The  determination  of  what  time  was  “yellow”  weather  is  a  more  subjective 
issue.  This  is  not  only  true  of  this  demonstration,  but  is  also  true  for  the  human 
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operators  at  all  three  GEODSS  sites,  as  well  as  the  MSSS  site.  There  is  a  great  deal  of 
judgment  involved  in  when  to  call  the  weather  yellow.  The  operator  goes  outside,  looks 
at  the  sky,  determines  the  cloud  cover,  determines  which  areas  of  the  sky  are  clear  and 
which  are  not,  and  arrives  at  a  decision.  Different  operators  will  usually  come  up  with 
different  thresholds.  For  this  discussion,  the  metric  we  used  was  to  look  at  the  Catalog 
Star  Match  Percentage  (refer  to  the  plots  in  a  later  section).  This  is  the  number  of 
cataloged  stars  that  SOA  detected  in  the  image,  compared  to  the  number  that  should 
have  been  in  the  image,  expressed  as  a  percentage.  When  there  is  high  cirrus,  for 
example,  not  all  stars  will  be  visible.  For  the  purposes  of  this  report,  the  weather  was 
determined  to  be  yellow  if  a  significant  number  of  images  had  match  percentages  lower 
than  80%.  SOA  performed  this  analysis  on  an  hourly  basis. 

D.  Implementation  Cost  Estimates 
1.  Independent  Cost  Estimate 

One  of  the  innovative  advantages  of  the  SOA  concept  is  low  implementation 
and  operations  cost.  The  Space  Battlelab  obtained  an  independent  cost  estimate  from 
Aerospace  Corporation  (see  Table  10)  to  aid  HQ  AFSPC  in  their  decision  making 
process.  The  Aerospace  Corporation  provides  independent  cost  estimates  for 
AFMC/SMC  acquisitions.  After  review  of  the  Aerospace  data  and  discussions  with 
AFMC/ESC  and  AFSPC/DRC  we  estimate  that  $5-7  million  would  be  sufficient  to 
acquire,  deploy  and  integrate  three  systems  into  the  SSN.  The  annual  operations  and 
maintenance  (O&M)  cost  for  three  sites  would  be  ~$800,000. 

Aerospace  assumed  an  independent  contractor  would  acquire  a  SOA  system 
from  scratch,  without  the  benefit  of  lessons-leamed  for  the  Space  Battlelab 
demonstration.  The  availability  of  this  report,  AFRL  personnel,  and  AFRL  software  for 
future  reference  should  reduce  the  program  development  risk  and  make  this  a 
conservative  cost  estimate.  Aerospace  also  estimated  the  recurring  system  acquisition 
cost  and  annual  O&M  cost.  Aerospace  did  not  include  any  System  Program  Office 
(SPO)  overhead  cost  in  the  figures,  estimated  as  an  additional  20  -  25%  of  the  program 
cost. 


One  item  not  included  in  the  cost  estimate  is  integration  with  the  OC3F.  The 
current  OC3F  cannot  handle  non-GEODSS  standard  telescopes,  including  TOS.  The 
cost  to  modify  the  OC3F  for  non-standard  telescopes  is  ~$1  million.  The  recurring  cost 
would  be  approximately  $100,000.  These  are  Rough  Order  of  Magnitude  (ROM)  costs 
from  discussions  with  AFMC/ESC  and  their  OC3F  development  contractor,  PRC. 
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Common  Su 


Facilities 
SECRET  Fadlil 
Site  Activation 
Trainin 


System  In 

■ 

■ 

bmb 

91.7 

System  Program  Level 

System  Engineering 

104.3 

114.6 

Program  Management 

104.3 

114.6 

stem  Test  &  Evaluation 


■ 

■■ 

Officers 

0.0 

Enlisted 

0.0 

Contractor 

20.0 

Program  Mgt 

40.0 

Hardware  (DEV) 

0.0 

Hardware  (COTS) 

21.0 

Software  (COTS) 

7.5 

Software  (DEV)  | 

97.6 

Sustaining  Engineering 

52.1 

Modifications 

20.9 

Logs  tics 

31.3 

Fad  li  ties 

0.0 

Electricity 

0.0 

Backup  Power 

0.0 

HVAC  j 

0.0 

Maintenance  Contract 

0.0 

Security 

1 - 

_ 

0.0 

$90K/person  (0) 


$45K/person  (0) _ 

$160K/person  (1)  w/ travel 
$1 60K/pe  rson  { 1 )  w/  travel 


1-3%  PMP  Development  hVW 


5-15%  Dev  WV _ 

20-33%  of  COTS _ 

10-15%  PMP  SW 


2%  PMP _ 

3-5%  PMP _ 

10%  Facilities  (Acq) 


TABLE  10  Aerospace  Cost  Estimate 


In  Table  10  the  first  column  is  a  description  of  the  elements  considered  in  the 
cost  estimate. 
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The  second  cost  column  assumes  the  acquisition  and  deployment  of  the 
basic  SOA  system  to  Edwards  AFB.  It  has  $0.00  for  the  Facilities,  SECRET  Facilities, 
and  Site  Activation  because  the  18  SPSS  is  an  existing  facility  that  would  provide 
services.  The  O&M  cost  does  not  include  any  Leased  Line  cost  because  the  18  SPSS 
would  provide  communications.  The  O&M  budget  includes  the  overhead  of  a  “primary” 
site  that  provides  system  upgrades  for  remote  site  installation. 

The  third  column  shows  an  upgraded  SOA  system  that  includes  a  1 -degree 
field-of-view  telescope  with  a  tracking  mount.  Although  this  doubles  the  total  hardware 
cost,  the  total  cost  increases  by  only  ten  percent. 

The  fourth  column  is  the  recurring  cost  for  a  site  in  Italy  with  an  upgraded 
SOA  system.  We  assumed  TDY  personnel  would  provide  maintenance  on  an  as- 
needed  basis  (approximately  every  60  days).  Note  that  the  Software  (DEV)  cost  is  $0.0 
and  the  greatly  reduced  Sustaining  Engineering  cost  from  the  “primary"  site. 

The  fifth  column  is  the  recurring  site  cost  for  Australia  (consistent  with  the 
SOA  demonstration)  with  a  1/2  degree  FOV  telescope. 

The  last  column  is  the  basis  of  estimate. 

2.  Operational  Cost  Comparison 

One  of  the  essential  drivers  in  a  decision  to  acquire  a  system  is  the  long  term 
O&M  cost.  The  advantages  of  the  SOA  concept  with  COTS  based  hardware  and 
software,  and  un-manned  operations  are  clear. 


Objects  / 

O&M  cost/  Operators/ 

site 

object 

site 

Baseline  GEODSS 

-125 

$38 

9 

Refurbished  GEODSS 

-450 

$15 

9 

(POMed  for  Sustainment) 

SOA 

-450 

$6 

0 

(3  telescopes) 

$5-7M 

TABLE  1 1  Long  Term  O&M  Cost  Comparison 
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As  can  be  seen  in  Table  1 1 ,  the  AFSPC  GEODSS  refurbishment  effort  of 
~$60million  will  have  significant  long  term  O&M  cost  impacts.  However,  the  O&M  cost 
per  object  for  the  SOA  concept  is  2.5  times  less  than  the  refurbished  GEODSS.  The 
SOA  concept  is  clearly  a  cost-effective  investment. 

4.  CONCLUSION 

A.  Deployment 

HQ  AFSPC  should  address  the  SSN  coverage  and  capacity  limitations  for  deep 
space  objects.  Too  many  objects  receive  inadequate  tracking  and  the  problem  will  only 
get  worse  as  the  number  of  objects  on-orbit  increases.  Therefore,  the  Space  Battlelab 
believes  that  HQ  AFSPC  should,  at  a  minimum,  acquire  three  upgraded  SOA  systems 
with  a  1 -degree  FOV  telescopes  and  tracking  mounts. 

HQ  AFSPC  should  deploy  the  three  systems  to  ensure  redundant  coverage  of 
deep  space  as  shown  in  Figure  33.  The  site  in  Australia  would  cover  the  gap  in 
Australia  and  provide  partially  overlapping  coverage  for  Diego  Garcia.  The  European 
site  would  provide  overlapping  coverage  for  TOS  in  Moron,  Spain  and  provide  partially 
overlapping  coverage  for  Diego  Garcia.  The  site  in  Southwest  Asia  would  provide 
significant  overlap  for  both  Moron,  Spain  and  Diego  Garcia. 

In  addition  to  the  coverage  improvements,  the  SSN  capacity  would  also  improve 
as  shown  in  Figure  34.  Although  the  total  capacity  shortfall  still  exists,  three-telescope 
augmentation  should  allow  the  SSN  to  meet  the  GEODSS  ORD  requirement  to  track  all 
deep  space  objects  once  every  three  days.  In  addition,  SOA  should  significantly  reduce 
the  number  of  objects  on  the  attention  list  and  lost  list. 

B.  System  Configuration 

In  general,  the  system  configuration  used  for  the  SOA  demonstration  was 
successful.  However,  several  minor  design  implementation  issues  discussed  in  the 
report  (i.e.  communications  approach)  are  appropriate  for  a  SPO  to  consider  when 
acquiring  the  system.  The  Space  Battlelab  did  not  intend  the  demonstration  to  define 
fully  all  requirements  for  an  operational  system. 

There  are  two  hardware  changes  identified  during  the  demonstration  that  would 
substantially  improve  the  system  performance:  expand  the  telescope  FOV  and  minimize 
the  telescope  mount  limitations.  (1)  A  wider  FOV  telescope  would  increase  the  number 
of  objects  visible  to  the  system  as  discussed  in  section  3C4,  Minimum  and  Maximum 
Tracking  Rates,  and  allow  the  SOA  system  more  effectively  augment  the  SSN.  (2)  The 
telescope  mount  was  a  major  driver  in  the  system  performance  in  both  throughput  and 
acquisition  rate.  As  discussed  in  section  3C2,  Throughput,  a  mount  that  does  not  have 
meridian  crossing  limitations  would  simplify  OC3F  tasking  and  improve  system 
performance.  In  addition,  the  mount  should  have  the  ability  to  track  an  object  to  allow 
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the  system  to  operate  in  a  rate-track  mode.  The  acquisition  rate  for  the  system 
increased  when  in  rate-track  mode  as  described  in  section  3C5D,  Satellite  Category. 


Figure  33  SSN  DS  Coverage  with  3  SOA  Systems 


Figure  34  Capacity  Shortfalls  with  3  SOA  Systems 
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